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Summary 

This  report  describes  work  completed  towards  a  new  framework  for  distributed  multi-agent  planning 
and  plan  execution.  The  first  step  focusses  on  the  plan  representation  that  needs  to  be  sufficiently  rich 
to  allow  the  sharing  of  plans  between  humans,  software  systems,  and  robotic  entities.  The  basis  for  this 
representation  is  the  Core  Plan  Representation  developed  in  the  mid  90s.  This  representation  and  its 
roots  in  Artificial  Planning  research  are  examined  in  section  3.  The  fucus  of  this  representation  is  the 
concept  of  a  plan.  Plans  are  executed  by  agents,  and  one  of  the  dominant  models  of  agency  in  agent 
research  describes  three  mental  attitudes  of  an  agent:  beliefs,  desires  and  intentions.  In  section  4  we  shall 
examine  these  concepts  attempt  to  merge  them  with  the  plan  representation.  The  combined  ontology 
will  then  be  further  refined  in  section  5,  introducing  concepts  that  will  be  required  for  a  sharable  plan 
representation  intended  for  distributed  multi-agent  planning  and  plan  execution.  The  report  then  goes 
on  to  describe  the  software  support  for  this  representation,  which  has  been  developed  as  an  extension  to 
MediaWiki. 

The  next  part  of  this  report  defines  a  number  of  features  that  can  be  used  to  characterize  planning  do¬ 
mains,  namely  domain  types,  relation  fluency,  inconsistent  effects  and  reversible  actions.  These  features 
can  be  used  to  provide  additional  information  about  the  operators  defined  in  a  STRiPS-like  planning  do¬ 
main.  Furthermore,  the  values  of  these  features  may  be  extracted  automatically;  efficient  algorithms  for 
this  are  described  in  this  report.  Alternatively,  where  these  values  are  specified  explicitly  by  the  domain 
author,  the  extracted  values  can  be  used  to  validate  the  consistency  of  the  domain,  thus  supporting  the 
knowledge  engineering  process.  This  approach  has  been  evaluated  using  a  number  of  planning  domains, 
mostly  drawn  from  the  international  planning  competition.  The  results  show  that  the  features  provide 
useful  information,  and  can  highlight  problems  with  the  manual  formalization  of  planning  domains. 

In  the  final  part  of  this  report  the  focus  will  be  on  communication  about  activity  and  plans.  After  an 
analysis  of  existing  agent  communication  standards  and  interaction  protocols  defined  in  these  approaches 
we  will  define  a  small  number  of  more  complex  protocols  for  the  support  of  distributed  plan  execution. 
This  will  be  concluded  with  a  discussion  on  execution  failure  and  a  fundamental  problem  that  underlies 
all  existing  approaches. 
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1  The  Representation 


Planning  is  commonly  associated  with  intelligent 
behavior  in  agents  [Russell  and  Norvig,  2003].  The 
activity  of  planning  can  be  defined  as  an  explicit 
deliberation  process  that  chooses  and  organizes  ac¬ 
tions  by  anticipating  their  outcomes  and  which 
aims  at  achieving  some  pre-stated  objectives  [Ghal- 
lab  et  al,  2004].  Planning  in  Artificial  Intelligence 
(AI)  is  the  computational  study  of  this  deliberation 
process. 

The  outcome  of  the  planning  process  and  the 
solution  to  a  planning  problem  is  a  plan,  i.e.  an 
organized  collection  of  actions.  Most  research  in 
AI  planning  has  focussed  on  algorithms  for  finding 
plans,  which  has  proved  to  be  a  computationally 
very  hard  problem.  Assuming  that  an  agent  wants 
to  achieve  the  objective  that  underlies  the  planning 
problem,  it  will  also  need  to  execute  the  plan.  As¬ 
suming  further  that  more  than  one  agent  is  involved 
in  the  planning  and  execution,  the  plan  will  need 
to  be  communicated  between  the  different  agents, 
calling  for  a  rich  and  sharable  representation  of  a 
plan. 

2  The  Representation:  Meth¬ 
ods,  Assumptions,  and  Pro¬ 
cedures 

To  this  end,  the  Core  Plan  Representation  (CPR) 
[Pease  and  Carrico,  1996]  was  developed.  The  CPR 
establishes  a  conceptual  framework  for  the  rich  rep¬ 
resentation  of  plans  that  are  to  be  communicated 
between  agents.  The  concepts  provided  are  generic 
in  the  sense  that  they  will  be  important  for  most 
uses  of  a  plan,  be  it  for  execution  or  any  other  pur¬ 
pose.  Agents  using  these  concepts  in  the  represen¬ 
tation  of  their  plans  avoid  ambiguity  as  the  CPR  is 
a  standard  that  defines  these  concepts.  However, 
the  CPR  concepts  are  focussed  on  plans  and  the 
fact  that  these  plans  may  be  executed  by  agents  is 
almost  incidental. 

In  this  research  we  will  look  at  the  concept  of  a 
plan  as  it  is  defined  in  the  CPR,  but  we  will  shift  the 
emphasis  to  the  agents  that  work  with  this  plan.  To 
achieve  this  aim,  we  will  attempt  to  merge  the  main 
concepts  of  the  CPR  with  the  core  mental  attitudes 
established  in  research  into  intelligent  agents:  Be- 


Figure  1:  Main  concepts  of  the  CPR 

liefs,  Desires  and  Intentions  (BDI).  Furthermore, 
we  will  refine  a  number  of  the  concepts  involved. 
This  will  allow  for  an  even  richer  representation  for 
communicating  plans  between  agents. 

The  ultimate  aim  here  is  to  support  the  dis¬ 
tributed  execution  of  a  plan  (and  its  sub-plans)  by 
a  group  of  agents  in  a  dynamically  changing  envi¬ 
ronment.  However,  this  aspect  will  be  discussed  in 
future  reports. 

3  The  Core  Plan  Representa¬ 
tion 

The  prime  motivation  for  the  development  of  the 
CPR  was  to  address  the  plan  interchange  require¬ 
ments  of  several  military  planning  systems.  Just 
like  there  are  a  number  of  different  planning  prob¬ 
lems  and  approaches  in  AI,  there  are  different  rep¬ 
resentations  that  come  with  the  different  systems 
that  implement  the  various  approaches,  perhaps 
even  more.  Furthermore,  systems  that  process 
plans,  e.g.  workflow  systems,  control  systems,  etc., 
will  need  to  exchange  information  with  the  AI  plan¬ 
generating  systems.  And  we  must  not  forget  the 
human  in  the  loop:  people  need  to  understand 
plans  in  order  to  execute  them  in  line  with  the  in¬ 
tent  that  underlies  them. 

The  result  of  the  CPR  effort  is  a  small  ontology 
that  defines  a  few  core  concepts  that  are  expected 
to  be  shared  between  most  systems  that  deal  with 
plans.  The  way  these  concepts  are  defined  relies  on 
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ontological  principles:  each  concept  is  defined  by 
the  relations  that  must  hold  with  other  concepts 
and  some  internal  structure.  Furthermore,  there 
is  human-readable  text  that  explains  the  concepts, 
but  this  can  usually  not  be  processed  by  any  plan¬ 
ning  system. 

The  main  concepts  that  form  the  CPR  are  shown 
in  figure  1.  The  most  important  relation  that  holds 
between  these  concepts  is  the  “has  a”  relation  that 
indicates  that  an  instance  of  one  concept  has  a  com¬ 
ponent  that  is  an  instance  of  the  other  concept. 
Alternatively,  the  second  concept  forms  a  building 
block  for  the  former.  From  an  ontological  point  of 
view  this  is  slightly  unusual  as,  in  most  ontologies, 
the  “is  a”  relation  is  the  most  prominent  relation. 

3.1  Plans 

The  central  concept  in  the  CPR  is  of  course  the 
plan,  the  thing  the  CPR  is  meant  to  represent.  A 
plan  is  also  the  output  of  a  classic  AI  planning  sys¬ 
tem,  where  a  plan  is  an  organized  collection  of  ac¬ 
tions.  In  the  CPR,  the  definition  of  a  plan  includes 
more: 

•  name:  a  unique  reference  that  can  be  used  to 
refer  to  a  specific  plan; 

•  sub-plans:  a  set  of  finer  grained  plans  which 
correspond  to  a  hierarchical  decomposition  of 
the  overall  plan; 

•  objectives:  a  set  of  objectives  that  are  ac¬ 
complished  by  the  plan; 

•  actions:  a  set  of  actions  which  must  be  per¬ 
formed  as  part  of  this  plan; 

•  alternatives:  that  names  of  other  plans  (that 
were  considered); 

•  evaluation:  the  merits  of  this  plan  (compared 
to  its  alternatives);  and 

•  issues:  metadata  about  the  status  of  plan  cre¬ 
ation. 

Explicit  naming  of  plans  is  necessary  for  commu¬ 
nication  purposes.  The  inclusion  of  sub-plans  indi¬ 
cates  that  the  approach  is  based  on  a  classic  HTN 
planning  paradigm  [Tate,  1977],  where  a  planning 
problem  is  given  as  a  task  (an  activity)  to  be  accom¬ 
plished.  However,  the  nature  of  objectives  is  not 


well  defined  in  the  CPR:  objectives  could  be  tasks 
as  in  HTN  planning  or  they  could  be  state-related 
goals  as  in  STRIPS  planning  [Fikes  and  Nilsson, 
1971].  We  shall  assume  that  objectives  are  meant 
to  include  both.  Actions  will  be  considered  in  de¬ 
tail  below.  The  next  two  components,  alternatives 
and  merits,  are  usually  not  considered  in  classic 
planning,  but  are  of  great  practical  relevance  dur¬ 
ing  the  planning  process.  Finally,  issues  in  CPR 
are  a  generalization  of  flaws  in  AI  planning. 

3.2  Actions 

Actions  are  the  main  components  in  a  plan.  They 
correspond  to  activities  an  agent  can  do.  While 
plans  are  considered  too  complex  to  be  directly  ex¬ 
ecutable  by  and  agent  and  hence  require  being  bro¬ 
ken  down,  actions  can  be  considered  primitive  in 
that  an  agent  does  not  need  to  be  told  as  part  of 
the  plan  how  the  action  is  to  be  done,  i.e.  further 
decomposition  is  optional.  In  the  CPR,  an  action 
consists  of: 

•  name:  a  unique  reference  that  can  be  used  to 
refer  to  a  specific  action  in  a  plan; 

•  sub-actions:  a  set  of  finer  grained  actions 
which  correspond  to  a  hierarchical  decompo¬ 
sition  of  the  action  (e.g.  if  there  are  multiple 
actors)  ; 

•  actors:  a  set  of  agents  that  will  execute  the 
described  action; 

•  resources:  a  set  of  (reusable  and  consumable) 
resources  that  will  be  used  during  the  execu¬ 
tion  of  this  action; 

•  plan  objects:  a  set  of  objects  that  function 
as  parameters  to  this  action;  and 

•  begin  and  end:  two  time  points  representing 
the  beginning  and  the  end  of  this  action. 

Again,  explicit  naming  of  actions  is  useful  for 
communication.  The  decomposition  of  actions  into 
sub-actions  is  odd  from  a  planning  perspective: 
what  is  the  difference  between  a  plan  that  requires 
decomposition  and  an  action  that  requires  decom¬ 
position?  One  difference  is  that  actions  are  associ¬ 
ated  with  actors,  the  agents  that  execute  the  action. 
Furthermore,  actions  are  associated  with  resources 
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used  by  the  action,  giving  an  action  a  more  con¬ 
crete  feel  than  a  plan,  and  making  them  the  sub¬ 
ject  of  scheduling  algorithms  rather  than  planning 
in  AI  terminology.  The  same  is  true  for  beginning 
and  end  time  points,  which  are  usually  assigned  by 
schedulers. 

3.3  Actors 

While  plans  and  actions  are  concepts  firmly  rooted 
in  classic  AI  planning,  the  concept  of  an  actor  has 
not  received  much  attention  in  the  planning  litera¬ 
ture.  However,  there  is  another  area  of  AI,  multi¬ 
agent  systems  [Wooldridge  and  Jennings,  1995; 
Wooldridge,  1999],  in  which  the  concept  of  an  agent 
is  central.  More  on  this  below.  In  the  CPR,  an  ac¬ 
tor  is  a  relatively  simple  concept: 

•  name:  a  unique  reference  that  can  be  used  to 
refer  to  a  specific  actor; 

•  objectives:  a  set  of  of  objectives  this  actor 
shares  with  the  plan;  and 

•  sub-actors:  a  set  of  actors  if  this  is  an  aggre¬ 
gate  actor. 

The  objectives  here  are  a  subset  of  the  objectives 
that  are  associated  with  a  plan  to  which  an  ac¬ 
tion  assigned  to  this  actor  belongs.  This  allows  for 
the  limited  representation  of  rationale  in  the  plan, 
which  can  be  most  useful  for  deciding  how  exactly 
to  implement  an  action  or  during  execution  failure. 
The  representation  of  sub-actors  allows  for  the  rep¬ 
resentation  of  hierarchical  organizations.  Whether 
an  actor  has  authority  over  its  sub-actors  is  not 
defined  in  the  CPR. 

3.4  Resources  and  Time  Points 

Resources  are  not  defined  formally  in  the  CPR. 
They  are  given  a  name  that  can  be  used  to  refer 
to  them,  and  they  are  used  by  actions,  but  other 
than  that,  it  is  up  to  the  planner  to  use  them  in  a 
meaningful  way.  Again,  AI  planning  does  not  deal 
much  with  resources  as  scheduling  algorithms  tend 
to  be  much  more  efficient  in  managing  them. 

The  same  applies  to  time  points  in  CPR,  except 
that  they  are  not  even  given  a  name.  This  may 
be  due  to  the  fact  that  time  has  a  common  sense 
meaning  and  is  exactly  that  which  is  used  here. 


3.5  Objectives  and  Evaluation  Cri¬ 
teria 

Objectives  come  in  two  forms  in  AI  planning,  as 
mentioned  above,  either  as  tasks  to  be  performed 
(activities)  or  goals  to  be  achieved  (world  state  con¬ 
ditions).  Either  way,  they  are  part  of  the  planning 
problem,  but  usually  not  part  of  the  plan  that  is  a 
solution  to  a  planning  problem. 

In  the  CPR  an  objective  contains  the  following 
attributes:  type,  value,  actions,  evaluation  crite¬ 
ria,  and  sub-objectives.  The  actions  are  those  that 
contribute  to  this  objective.  They  may  also  con¬ 
tribute  to  other  objectives,  and  actors  that  execute 
these  actions  should  have  this  objective  as  one  of 
their  objectives  to  be  consistent.  Associated  with 
an  objective  is  a  set  of  evaluation  criteria. 

Like  resources  and  time  points,  evaluation  crite¬ 
ria  are  not  defined  in  terms  of  attributes  within  the 
CPR. 

4  Beliefs,  Desires  and  Inten¬ 
tions 

A  BDI  agent  is  distinguished  by  the  organization 
of  its  knowledge,  which  governs  its  behavior,  into 
three  distinct  knowledge  structures  based  on  the 
mental  state  modalities:  beliefs ,  desires  and  inten¬ 
tions  [Rao  and  Georgeff,  1991].  Beliefs  represent 
the  agent’s  current  knowledge  about  itself  and  its 
environment,  desires  represent  its  longer  term  goals 
and  objectives  of  its  behavior,  and  intentions  rep¬ 
resent  the  agent’s  local  decisions  about  the  actions 
it  intends  to  perform. 


4.1  Semantics 

The  three  core  concepts  that  make  up  the  BDI 
model  are  not  defined  in  the  style  of  an  ontology, 
but  rather  through  an  operational  semantics.  A 
BDI  agent  executes  its  behavior  by  manipulating 
its  internal  knowledge  and  data  according  to  the 
standard  BDI  inference  loop: 
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function  BDI-inference-loop(f?e/,  Des ,  Int) 
while  true  do 

p  <—  getNextPerceptQ 
Bel  <—  beliefRevision(5d,p) 

Int  <—  generateOptions(i?el,  Des ) 
Int  4—  fi lterlntentions ( B el ,  Des,  Int ) 
plan  <—  generatePlan(_Be^,  Int) 
execute  (pi  an) 


A  BDI  agent  first  processes  the  next  external 
percept  (such  as  an  incoming  message).  As  a  re¬ 
sult  the  agent  revises  its  beliefs.  Then,  based  on 
the  new  beliefs,  it  generates  several  different  inten¬ 
tional  options  out  of  which  one  is  adopted  by  means 
of  the  filterlntention  function.  Next,  the  gener- 
atePlan  function  elaborates  a  plan  for  the  adopted 
intentions  that  is  then  executed.  In  applications  of 
the  BDI  model  this  planning  process  is  often  based 
on  pattern-matching  against  a  library  of  predefined 
plans. 

The  BDI  model  is  one  of  an  agent  that  fulfills 
three  key  qualities:  autonomy,  reactivity  and  in- 
tentionality  [Wooldridge  and  Jennings,  1995].  The 
BDI  model  does  not  explicitly  support  the  social 
properties  of  an  agent:  the  ability  to  communicate, 
cooperate  and  reason  about  other  agents  in  a  multi¬ 
agent  community. 

4.2  Task-Centric  BDI 

Implementations  of  the  BDI  model  are  often  very 
simple  in  that  they  are  based  on  a  propositional 
representation:  beliefs  are  sets  of  propositional 
symbols  that  hold  in  a  given  world  state;  desires 
and  intentions  are  also  propositions,  namely  the 
conditions  the  agent  desires  or  intends  to  make  true 
in  a  future  state  of  the  world.  Defined  like  this,  the 
BDI  model  can  be  reasoned  about  with  classic  theo¬ 
rem  provers  quite  easily.  However,  a  more  complex 
implementation,  e.g.  using  first-order  atoms  as  be¬ 
liefs  means  current  theorem  provers  are  insufficient 
to  work  as  interpreters  for  an  agent  specified  at  the 
BDI  level. 

For  this  reason  we  have  adopted  a  task-centric 
view  of  an  agent,  in  which  beliefs  are  essentially 
sets  of  first-order  atoms,  and  desires  and  intentions 
are  described  by  tasks  to  be  accomplished  and  plans 
to  be  executed  respectively  [Wickler  et  al,  2007]. 


Figure  2:  Main  concepts  of  the  BDI  model 

In  this  view,  an  HTN  planner  can  be  used  as  an 
agent  interpreter. 

5  Combining  CPR  and  BDI 

In  this  section  we  will  present  a  combined  view  of 
the  main  concepts  from  the  CPR  and  the  BDI  agent 
model.  We  will  then  continue  to  extend  the  model 
by  refining  the  different  concepts  in  order  to  enrich 
the  representation.  The  aim  is  to  come  up  with 
a  model  that  allows  semantically  rich  plans  to  be 
shared. 

5.1  Ontological  View 

Despite  the  name  (BDI) ,  the  central  concept  of  this 
model  is  the  agent.  An  agent  is  defined  by  its  men¬ 
tal  attitudes  just  like  a  plan  in  the  CPR  is  defined 
by  its  attributes.  Thus,  an  agent  is  defined  by  a  set 
of  beliefs,  a  set  of  desires,  and  a  set  of  intentions, 
as  shown  in  figure  2. 

The  concept  of  a  BDI  agent  represents  essentially 
the  same  concept  as  a  CPR  actor.  In  both  cases, 
these  are  the  entities  that  execute  actions  and  de¬ 
liberately  manipulate  the  world  according  to  some 
mental  model.  There  are  some  differences  though: 
In  the  BDI  model  the  mental  attitudes  are  the  fo¬ 
cus,  whereas  the  CPR  only  mentions  the  objectives 
of  an  agent,  and  only  those  relevant  to  the  plan  in 
which  the  actor  occurs  are  considered.  The  BDI 
model  on  the  other  hand  ignores  the  internal  struc- 
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Figure  3:  Plans  as  <I-N-C-A>  objects 

ture  of  an  agent  that  may  be  an  organization  with 
sub-actors;  it  only  considers  individual  agents. 

Objectives  can  be  tasks  to  be  accomplished  or 
goals  to  be  achieved.  They  correspond  to  desires 
in  the  task-centric  or  the  classic  BDI  model  respec¬ 
tively.  In  HTN  planning  there  is  no  real  distinction 
between  a  task  which  can  be  given  as  input  to  a 
planner  and  a  plan  that  is  the  corresponding  out¬ 
put;  both  are  plans.  The  difference  is  that  a  task 
usually  requires  refinement  before  it  becomes  an  ex¬ 
ecutable  plan,  and  that  is  exactly  what  refinement 
planners  do  [Kambhampati  et  al.,  1995]. 

5.2  Refining  the  Concepts 

The  nine  concepts  introduced  so  far  can  be  used  as 
the  core  of  a  sharable  plan  representation.  In  the 
remainder  of  this  section  we  will  refine  and  extend 
these  concepts  by  extending  the  ontology.  This  will 
include  relations  that  must  hold  between  the  var¬ 
ious  concepts,  resulting  in  a  more  tightly  defined 
semantics. 

5.2.1  Plans  as  Activity  Networks 

The  first  refinement  to  be  introduced  here  is  based 
on  the  <I-N-C-A>  ontology  [Tate,  2003]  which  de¬ 
scribes  a  plan  consisting  of  four  main  components: 
issues,  nodes,  constraints  and  annotations.  Despite 
different  terminology  used,  the  <I-N-C-A>  model  is 
really  an  extension  of  the  CPR  model,  where  both, 
an  <I-N-C-A>object  and  a  plan  are  in  fact  a  speci¬ 


fication  of  an  activity  network,  and  this  is  the  term 
we  have  used  in  figure  3. 

Given  that  the  <I-N-C-A>  model  is  meant  for 
describing  any  type  of  synthesized  object,  not  just  a 
plan,  its  terminology  is  also  more  general,  referring 
to  the  synthesized  components  as  nodes.  We  can 
be  more  specific  here:  in  a  plan  the  synthesized 
components  are  activities.  An  activity  corresponds 
directly  to  an  action  in  the  CPR.  However,  the  term 
action  has  been  heavily  overloaded  in  the  planning 
literature,  making  it  more  convenient  to  adopt  the 
term  activity  here.  Activities  will  be  discussed  in 
detail  below. 

A  second  component  already  included  in  the 
CPR  is  the  constraint.  However,  we  omitted  this 
concept  here  as  it  was  included  in  the  CPR  ontol¬ 
ogy  but  not  related  to  any  of  the  other  concepts. 
<I-N-C-A>  has  constraints  as  main  components  of 
a  plan.  In  fact,  the  objective  of  a  plan  can  be  it¬ 
self  a  constraint,  one  that  must  be  included  in  a 
plan.  This  is  coherent  with  the  view  that  a  plan 
is  a  specification  of  behavior,  and  the  objective  is 
a  special  constraint,  namely  that  any  refinement  of 
the  specification  must  include  the  achievement  of 
the  objective. 

Issues  have  no  equivalent  concept  in  CPR  or  BDI. 
One  interpretation  of  an  issue  is  a  meta-level  activ¬ 
ity,  i.e.  something  that  needs  to  be  done  at  the 
planning  level.  For  example,  flaws  that  need  to  be 
resolved  can  be  seen  as  issues  that  exist  within  a 
plan.  A  more  general  view  in  line  with  the  general 
synthesis  problems  for  which  <I-N-C-A>  is  suitable, 
an  issue  is  a  question  [Conklin,  2005]  that  needs  to 
be  answered  about  the  plan. 

Finally,  annotations  can  be  used  to  capture  any 
additional  information  about  the  plan  or  elements 
of  it,  e.g.  rationale  [Wickler  et  al.,  2006]. 

5.2.2  Actions  and  Activities 

Activities  are  an  extension  of  actions  in  the  CPR 
and  the  new  components  are  shown  in  figure  4.  As 
in  the  CPR,  we  must  have  an  actor  (agent)  asso¬ 
ciated  with  an  activity.  This  may  be  the  agent 
executing  the  activity,  or  at  least  being  responsible 
for  it.  An  activity  may  rely  on  a  given  set  of  re¬ 
sources,  and  an  activity  has  at  least  two  time  points 
associated  with  it,  the  beginning  and  the  end.  Fur¬ 
ther  time  point  may  be  specified  depending  on  the 
complexity  of  the  representation. 
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Figure  4:  Refined  activities 


Figure  5:  Types  of  belief  of  an  agent 


From  the  more  traditional  view  of  planning  we 
have  also  taken  the  signature,  preconditions  and 
effects  as  elements  of  an  activity.  The  signature  is 
simply  a  refinement  of  the  name  attribute  that  is 
defined  in  the  CPR.  The  signature  itself  consists 
of  a  name  that  denotes  the  activity  type,  corre¬ 
sponding  to  a  STRIPS  operator  name,  and  a  set  of 
(typed)  parameters  representing  the  objects  manip¬ 
ulated  by  this  activity.  In  the  CPR  these  objects 
were  directly  associated  with  the  activity  as  plan 
objects. 

Preconditions  and  effects  are  again  taken  from 
a  STRIPS  planning  view  and  there  did  not  ap¬ 
pear  to  be  a  corresponding  field  in  the  action  of 
the  CPR.  Both  are  world  state  conditions,  usually 
represented  as  atoms  of  first-order  logic.  More  com¬ 
plex  representations  are  possible  here.  If  there  is  an 
agreed  ontology  of  activity  types  that  is  shared  be¬ 
tween  all  agents,  then  there  is  no  need  to  explicitly 
include  preconditions  and  effects  in  the  plan  as  they 
are  indirectly  available  through  the  ontology. 

The  reason  why  they  are  important  is  that  pre¬ 
conditions  need  to  be  verified  at  execution  time: 
when  an  agent  is  about  to  start  an  activity  it  should 
check  that  all  the  preconditions  hold  to  ensure  that 
the  context  for  executing  the  activity  in  the  current 
plan  is  indeed  given.  Similarly,  when  the  activity 
is  completed,  the  agent  should  check  that  all  the 
required  effects  have  been  achieved. 


5.2.3  Types  of  Beliefs 

Beliefs  are  the  statements  an  agent  believes  to  hold 
in  the  world  at  given  point  in  time.  For  the  a 
plan  to  be  shared  it  is  important  for  the  agents  in¬ 
volved  to  share  certain  beliefs,  which  is  why  these 
should  be  included  in  a  rich  plan  representation. 
An  overview  of  the  types  of  beliefs  we  have  identi¬ 
fied  is  given  in  figure  5. 

Firstly,  there  are  beliefs  about  the  world  state. 
This  is  factual  knowledge  about  relations  that  hold 
between  objects  at  specific  points  in  time.  These 
can  be  in  the  past,  present,  or  future.  The  knowl¬ 
edge  is  static  in  the  sense  that  it  represents  time 
slices  of  world  states  and  does  not  include  relations 
that  go  from  one  time  slice  to  another. 

Second,  there  is  knowledge  about  capabilities  of 
different  agent.  In  a  collaborative  environment 
agents  need  to  know  what  others  are  capable  of 
doing.  Thus,  each  capability  is  associated  with  an 
agent.  The  capability  itself  is  given  as  the  signature 
of  the  activity  the  agent  is  capable  of  performing. 
The  signature  effectively  is  a  pointer  to  a  more  elab¬ 
orate  description  in  the  shared  ontology.  It  is  not 
expected  that  the  capability  is  always  available,  or 
in  all  circumstances.  To  use  the  capability  of  an¬ 
other  agent  in  a  plan,  some  negotiation  with  that 
agent  needs  to  take  place,  either  at  planning  time, 
or  at  execution  time  which  can  lead  to  failure  of 
course. 

Next,  there  are  methods  known  to  an  agent.  This 
is  procedural  knowledge  that  is  necessary  during 
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the  (HTN)  planning  process.  Technically,  there  are 
sometimes  known  as  refinements  as  they  describe 
how  a  complex  activity  can  be  refined  into  some¬ 
thing  that  is  closer  to  an  executable  plan,  e.g.  by 
breaking  the  activity  down  into  sub-activities  that 
are  organized  in  some  way.  Thus,  the  result  of  the 
refinement  is  itself  an  <I-N-C-A>  object,  i.e.  a  plan. 
In  the  procedural  knowledge  of  the  agent  this  is  as¬ 
sociated  with  the  activity  that  can  be  refined  by 
this  method. 

Finally,  an  agent  needs  to  know  what  activities  it 
can  execute  directly,  i.e.  without  further  planning. 
Each  of  these  is  described  by  the  signature  of  the 
activity. 

Note  that  this  representation  does  not  include 
knowledge  about  knowledge  of  other  agents.  While 
this  is  sometimes  necessary  for  reasoning,  it  is  also 
a  complex  problem  that  we  con  not  address  ade¬ 
quately  yet. 

5.2.4  Desires  and  Intentions 

As  mentioned  above,  desires  and  intentions  are 
both  represented  as  activity  networks  (plans)  in 
this  representation.  Both  can  be  seen  as  an  agenda 
though  which  agent  behavior  is  guided.  The  dif¬ 
ference  lies  in  the  fact  that  the  agent  holding  the 
desires  and  intentions  is  committed  to  only  the  in¬ 
tentions.  The  commitment  may  be  to  itself,  or  it 
may  be  to  one  or  more  other  agents.  In  the  latter 
case  an  activity  that  is  a  commitment  cannot  sim¬ 
ply  be  dropped,  but  there  must  be  a  way  of  nego¬ 
tiating  this  with  the  other  agents  the  commitment 
is  to.  There  are  no  commitments  with  respect  to 
desires. 

Note  that  a  special  type  of  activity  is  planning. 
Thus,  and  agent  may  have  an  intention  to  plan  for 
one  of  its  desires  (at  a  future  point  in  time).  This 
can  then  result  in  the  agent  adopting  that  plan  as 
an  intention,  scheduled  to  be  executed.  If  this  new 
plan  contains  another  planning  activity,  this  ap¬ 
proach  can  be  used  to  control  a  robotic  agent. 

5.2.5  Execution  Status 

The  final  concept  to  be  described  here  is  not  men¬ 
tioned  in  either  the  CPR  or  the  BDI  model,  but  it 
is  clearly  relevant  for  plan  execution:  the  execution 
status  of  a  plan.  As  this  a  rather  simple  component 
at  this  stage,  no  figure  is  necessary  to  describe  it. 


The  execution  status  of  a  plan  is  simply  defined  as 
the  completed  actions,  the  actions  in  progress,  and 
the  actions  still  to  do.  Each  of  these  actions  must 
be  associated  with  an  agent  in  the  plan. 

If  the  plan  can  be  executed  without  problems, 
this  simple  structure  will  suffice  to  describe  the  ex¬ 
ecution  status  os  a  plan.  However,  plan  plans  tend 
to  go  wrong,  especially  in  military  domains  where 
adversaries  have  an  active  interest  in  disrupting 
plans.  This  means  plan  repair  and  re-planning  may 
need  to  occur  as  part  of  the  plan  execution.  The 
plan  execution  status  must  capture  this.  Thus,  fur¬ 
ther  research  is  required  to  establish  concepts  and 
structures  that  can  capture  this  process  and  the 
(dynamic)  plan  adequately. 

6  The  Implementation 

The  sharing  of  information  online  has  progressed 
significantly  with  the  advent  of  Web  2.0  technology, 
where  the  content  of  websites  can  be  dynamically 
updated  by  the  users  of  that  site.  One  of  the  tech¬ 
nologies  that  implements  this  approach  are  wikis, 
of  which  MediaWiki  [Barrett,  2008]  is  one  of  the 
most  popular  and  robust.  Information  in  a  wiki  is 
usually  more  or  less  free  form,  which  has  the  advan¬ 
tage  that  anything  can  be  written  down  and  shared. 
The  drawback  is  that  unstructured  information  al¬ 
lows  for  only  limited  automated  processing. 

7  Implementation:  Methods, 
Assumptions,  and  Proce¬ 
dures 

To  address  this  issue,  MediaWiki  has  an  extension 
mechanism  that  allows  for  arbitrary  XML  tags  to 
be  defined,  and  this  is  the  approach  we  have  chosen 
to  develop  a  semi-formal  software  tool  that  sup¬ 
ports  the  development  of  rich  and  sharable  plan¬ 
ning  and  plan  information.  The  concepts  identified 
in  the  first  report  are  implemented  as  XML  ele¬ 
ments  that  can  be  used  in  an  otherwise  free-form 
document.  This  means  people  can  develop  plans 
and  planning  knowledge  even  if  they  are  not  ex¬ 
perts  in  the  formal  aspects  of  the  representation. 
Other  people  could  then  mark  up  the  content  using 
the  formal  concepts  provided  by  the  CPR/BDI  rep- 
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resentations.  MediaWiki  provides  the  mechanisms 
for  collaborative  article  development  and  sharing. 

This  report  describes  the  implementation  of  the 
different  elements  that  come  with  the  extension  to 
MediaWiki.  It  can  be  seen  as  a  reference  manual 
that  illustrates  the  different  concepts  using  a  rela¬ 
tively  simple  domain  that  is  used  in  the  literature 
on  AI  planning. 

8  Representing  Procedural 
Knowledge  in  a  Wiki 

In  this  section  we  will  describe  the  formal  syntax 
of  a  mark-up  language  that  has  been  implemented 
as  part  of  the  extension  of  MediaWiki  [Barrett, 
2008].  This  language  defines  a  number  of  XML 
tags  that  can  be  used  give  wiki  text  describing  pro¬ 
cedural  knowledge  a  formal  meaning  that  can  then 
be  exploited  for  formal  reasoning  about  the  proce¬ 
dures  represented  in  the  wiki  articles.  The  concepts 
that  are  represented  by  the  formal  language  were 
described  by  a  semi-formal  ontology  in  [Wickler, 
2010],  and  an  overview  of  these  concepts  is  repeated 
here  in  figure  6 

The  implementation  of  most  of  these  concepts 
involves  three  steps.  Firstly,  the  XML  tags  that 
define  wiki  text  to  have  a  specific  formal  mean¬ 
ing  must  be  declared.  These  tags  can  then  appear 
in  the  source  of  a  wiki  article.  We  shall  illustrate 
the  use  of  these  tags  with  various  examples.  Sec¬ 
ondly,  the  marked  up  text  that  represents  instances 
of  concepts  from  the  CPR/BDI  ontology  in  figure 
6  must  be  stored  in  a  database.  This  has  been  ac¬ 
complished  by  adding  a  set  of  new  tables  to  the 
database  used  by  MediaWiki,  and  the  SQL  state¬ 
ments  used  to  create  these  tables  will  be  given  as 
precise  definitions  of  the  entities  extracted  from  an 
article.  Finally,  the  source  wiki  text  has  be  ren¬ 
dered  to  make  it  readable  for  an  average  user  not 
familiar  with  wiki  text  or  the  XML  tags  described 
here.  We  shall  used  a  series  of  sample  screen  shots 
to  illustrate  how  the  text  is  currently  rendered. 

8.1  Fundamentals:  Conditions 

Before  we  develop  the  different  concepts  from  the 
CPR/BDI  ontology,  however,  we  shall  look  at  one 
fundamental  concept  that  is  shared  by  many  of  the 


more  complex  structures:  a  logical  literal.  In  first- 
order  logic  this  represents  an  atomic  relation  be¬ 
tween  several  arguments,  or  a  negation  of  such  an 
atomic  relation.  The  relation  itself  is  represented 
by  a  logical  symbol,  i.e.  a  name  used  to  refer  to 
this  relation.  The  arguments  typically  represent 
objects  that  exist  in  the  domain  of  interest,  and 
they  too  are  given  names  that  can  be  used  to  refer 
to  them.  The  following  represents  two  such  atoms 
representing  world  state  conditions: 

<atom> 

<rel  name="belong"  /> 

Cobject  name="kl"  /> 

Cobject  name="ll"  /> 

</ atom> ; 

<atom> 

<rel  name="belong"  /> 

Cobject  name="k2"  /> 

Cobject  name="12"  /> 

</ atom> ; 

This  is  example  is  taken  from  a  toy  domain  com¬ 
monly  used  in  the  AI  planning  community:  the 
dock  worker  robots  domain  [Ghallab  et  al. ,  2004]. 
The  rel  XML  element  defines  a  logical  relation 
that  must  have  exactly  one  attribute,  its  name, 
which  can  be  an  arbitrary  string.  The  arguments 
to  this  relation  are  defined  using  the  object  ele¬ 
ment  which  also  assumes  one  attribute  name.  Rela¬ 
tions  and  objects  are  grouped  together  in  an  atom 
element.  The  example  states  that  there  is  a  crane 
(kl)  which  is  at  location  11,  and  another  crane  (k2) 
at  location  12. 

Logical  literals  like  this  are  used  in  world  state 
information,  preconditions  and  effects  of  actions, 
goal  descriptions,  and  a  number  of  other  concepts 
from  the  CPR/BDI  ontology.  The  are  stored  in  a 
table  of  conditions  that  is  crested  as  follows: 

create  table  mw_plan_cond  ( 
aid  int  unsigned  not  null, 
cid  int  unsigned  not  null, 
sign  bool  not  null, 
cond  varchar (128)  not  null, 
role  int  unsigned  not  null, 
owntype  int  unsigned  not  null, 
ownid  int  unsigned  not  null, 

primary  key  (aid,  cid) 

); 
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Figure  6:  Main  concepts  of  the  CPR/BDI  Representation 
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The  aid  field  is  defined  for  every  table  holding 
instances  of  procedural  knowledge  and  simply  ref¬ 
erences  the  article  in  which  a  specific  knowledge 
element  (here,  a  logical  condition)  has  been  de¬ 
fined.  The  cid  is  the  unique  index  of  this  con¬ 
dition.  The  condition  itself  consists  of  a  sign  indi¬ 
cating  whether  this  is  a  positive  or  negative  atom, 
and  a  string  representation  of  the  condition  in  the 
field  cid.  The  role  indicates  how  this  condition 
is  used,  e.g.  as  a  precondition  or  as  an  effect.  Fi¬ 
nally,  there  is  information  about  the  container  of 
this  condition,  namely  its  type  in  owntype  and  the 
unique  reference  of  the  owner  in  ownid. 

Many  examples  of  rendered  conditions  will  follow 
in  the  remainder  of  this  report. 

8.2  Planning  Operators 

Operators  are  one  of  the  oldest  structures  that  were 
developed  for  the  representation  of  basic  activities. 
In  the  literature,  they  are  also  referred  to  as  action 
types,  or  simply  actions.  The  latter  is  often  used 
to  refer  to  instances  of  action  types  in  a  plan.  An 
operator  consists  of  a  name,  an  ordered  sequence  of 
parameters  describing  the  objects  that  are  manipu¬ 
lated  by  this  action  type,  and  a  set  of  preconditions 
and  effects.  The  following  is  an  example  of  wiki  text 
that  has  been  marked  up  as  an  operator: 

Coperator  name = "move "> 

Move  a  robot  from  one  location  to  another. 
<parameters> 

*  <var  name="r"  type="robot"  />:  the  robot 
which  will  be  moved  by  this  action; 

*  <var  name="from"  type="location"  />:  the 
location  from  which  the  robot  will  move 
away  (the  origin) ; 

*  <var  name="to"  type="location"  />:  the 
location  to  which  the  robot  will  move 
(the  destination) . 

</parameters> 

<preconditions> 

*  <atom> 

<rel  name=" adjacent"  /> 

<var  name="from"  /> 

<var  name="to"  /> 

</atom>:  the  origin  and  the  destination 
have  to  be  adjacent; 


*  <atom> 

<rel  name="at"  /> 

<var  name="r"  /> 

<var  name="from"  /> 

</atom>:  the  robot  has  to  be  at  the  origin 

*  <atom  sign="not"> 

<rel  name="occupied"  /> 

<var  name="to"  /> 

</atom>:  the  destination  must  not  be 
occupied. 

</preconditions> 

<ef f ects> 

*  <atom> 

<rel  name="at"  /> 

<var  name="r"  /> 

<var  name="to"  /> 

</atom>:  the  robot  will  be  at  the 
destination; 

*  <atom  sign="not"> 

<rel  name="occupied"  /> 

<var  name="from"  /> 

</atom>:  the  origin  will  no  longer  be 
occupied; 

*  <atom> 

<rel  name="occupied"  /> 

<var  name="to"  /> 

</atom>:  the  destination  is  now  occupied 
(by  the  robot) ; 

*  <atom  sign="not"> 

<rel  name="at"  /> 

<var  name="r"  /> 

<var  name="from"  /> 

</atom>:  the  robot  is  no  longer  at  the 
destination . 

</ ef f ects> 

The  above  definition  does  not  exclude  the 
origin  and  destination  being  the  same 
location.  While  this  does  not  constitute 
a  problem,  it  may  increase  the  size  of 
the  search  space  and  hence  slow  down 
the  planning  process. 

</ operator> 

The  name  of  the  operator  is  a  required  attribute 
of  the  operator  tag  and  must  be  unique.  This  ex¬ 
ample  also  shows  an  important  feature  of  the  repre¬ 
sentation,  that  is  not  used  much  here  in  the  interest 


15 


Distribution  A:  Approved  for  public  release;  distribution  is  unlimited. 


of  brevity:  the  tagged  information  is  only  part  of 
the  representation.  Any  information  that  is  not  di¬ 
rectly  part  of  a  formal  aspect  of  the  description  is 
simply  added  to  the  wiki  text  and  not  marked  up 
using  the  XML  tags.  This  text  will  be  rendered  by 
the  wiki  as  if  no  extension  was  present.  For  typical 
standard  operating  procedures,  it  is  expected  that 
this  constitutes  the  majority  of  the  description. 

The  parameters  are  a  sequence  of  variable  dec¬ 
larations.  Each  variable  (tagged  var)  must  have 
a  name  and  optionally,  a  type.  Again,  the  exam¬ 
ple  shows  that  normal  text  can  be  mixed  into  the 
representation  to  clarify  and  elaborate. 

The  preconditions  and  the  effects  of  an  oper¬ 
ator  are  conditions  of  the  type  described  in  the  pre¬ 
vious  section.  As  opposed  to  the  parameters,  the 
order  of  the  preconditions  and  effects  is  only  stored 
in  the  source  text,  but  may  be  different  when  the 
operator  is  exported  directly  from  the  database.  All 
the  arguments  to  the  various  conditions  associated 
with  an  operator  should  only  use  variables  that  are 
parameters  to  the  operator. 

The  database  uses  two  tables  to  store  the  oper¬ 
ators  (plus  the  conditions  table).  The  first  table 
holds  the  parameter  objects  with  their  respective 
types.  The  table  is  created  as  follows: 

create  table  mw_plan_param  ( 
aid  int  unsigned  not  null, 
pid  int  unsigned  not  null, 
name  varchar(16)  not  null, 
type  varchar (16) , 
pos  int  unsigned  not  null, 
owntype  int  unsigned  not  null, 
ownid  int  unsigned  not  null, 

primary  key  (aid,  pid) 

) ; 

The  pid  field  is  a  unique  reference  to  this  param¬ 
eter.  The  name  and  type  contains  the  respective 
attributes  from  the  XML  element.  The  position  of 
the  parameter  has  to  be  made  explicit  in  the  pos 
field  as  there  is  no  predefined  order  in  the  database. 

create  table  mw_plan_operator  ( 
aid  int  unsigned  not  null, 
oid  int  unsigned  not  null, 
name  varchar (64)  not  null, 
owntype  int  unsigned, 


ownid  int  unsigned, 
primary  key  (aid,  oid) 

) ; 

Since  both,  conditions  and  parameters  have  an 
explicit  link  to  their  owner,  the  operator  itself  has 
only  filed  that  represents  information  about  the  op¬ 
erator  directly,  namely  the  name  of  the  operator. 
As  opposed  to  conditions  and  parameters,  and  op¬ 
erator  need  not  occur  as  content  of  some  other  el¬ 
ement,  and  hence  the  owner  information  may  be 
null. 

When  an  article  that  contains  an  operator  is 
saved,  the  relevant  information  for  the  tables  men¬ 
tioned  above  is  automatically  extracted  from  the 
article  text  and  written  to  the  database.  Before  this 
is  done,  however,  any  CPR/BDI  objects  that  have 
the  current  article  id  are  deleted  from  the  database. 
This  ensures  that  updates  are  handled  correctly. 

The  rendered  article  containing  the  move  op¬ 
erator  is  shown  in  figure  7.  The  HTML  that  is 
generated  begins  with  the  heading  Action  Type: 
move.  The  parameters,  preconditions  and  effects 
are  listed  under  the  following  three  sub-headings. 
The  text  below  the  operator  is  simply  a  comment 
and  not  part  of  the  formal  CPR/BDI  representa¬ 
tion. 

8.3  Actions  in  a  Plan 

Action  types  define  the  way  the  application  of  an 
action  changes  the  world,  where  an  action  is  an 
instance  of  an  operator.  There  can  be  many  actions 
of  the  same  type  in  a  plan,  and  in  fact,  there  often 
are.  There  can  even  be  multiple  actions  having 
the  same  parameter  values  in  a  single  plan.  The 
following  example  shows  marked  up  wiki  text  that 
defines  a  single  action: 

<action  type="move" 
ref=" CTRL-20 11-1" 
agent=" controller" 
finish=" 2012-0 1-01  00:00:00"> 

<parameters> 

*  Cobject  name="rl"  />:  move  robot  nr.  1; 

*  Cobject  name="loc456"  />:  from  the  dock 
(the  origin) ; 

*  Cobject  name="loc789"  />:  to  the  yard 
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Figure  7:  An  Operator  rendered  in  the  Wiki 
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where  the  containers  are  (the 
destination) . 

</parameters> 

The  robot  can  now  be  loaded  with  a 
container . 

</ action> 

The  action  element  has  a  number  of  required 
attributes,  the  first  of  which  is  the  name  of  the  ac¬ 
tion  type  this  action  instantiates.  Since  the  action 
type  defines  the  preconditions  and  effects,  there  is 
no  need  for  them  in  the  action.  Another  attribute 
is  the  unique  reference  of  this  action,  which  can  be 
used  to  distinguish  otherwise  identical  actions  in 
a  plan.  Also  required  is  a  reference  to  the  agent 
that  has  to  execute  the  action,  which  is  simply  the 
name  of  the  agent.  Finally,  the  start  and  finish 
attributes  are  optional,  and  the  example  uses  only 
the  latter  to  set  a  deadline  for  the  action. 

The  content  of  an  action  element  is  a  single  list 
of  parameters.  Since  actions  must  be  fully  ground, 
all  the  parameters  are  objects,  as  described  in  the 
conditions  above. 

The  database  schema  that  describes  how  actions 
are  stored  is  defined  as  follows: 

create  table  mw_plan_action  ( 
aid  int  unsigned  not  null, 
uref  varchar(64)  not  null, 
descr  varchar(255)  not  null, 
agent  varchar(64)  not  null, 
abeg  datetime, 
aend  datetime, 
owntype  int  unsigned, 
ownid  int  unsigned, 

primary  key  (aid,  uref) 

); 

The  uref  field  contains  the  unique  user-defined 
reference  for  this  action.  The  description  in  descr 
contains  the  action  type  as  well  as  the  parameter 
values  for  the  action,  agent  abeg  and  aend  con¬ 
tain  attributes  from  the  action  element.  Finally, 
an  action  may  be  self  contained,  or  it  may  belong 
to  another  entity,  which  must  be  a  plan. 

The  wiki  text  formally  defining  an  action  is  ren¬ 
dered  by  our  extension  to  MediaWiki  as  shown  in 
the  lower  part  of  figure  8. 


The  time  points  are  defined  in  a  format  specific 
to  the  database,  but  this  could  be  formatted  in  dif¬ 
ferent  ways.  Again,  it  should  be  clear  that  the  ren¬ 
dered  text  should  be  accessible  to  any  user,  whereas 
the  source  text  is  not.  A  future  version  of  the  Me¬ 
diaWiki  extension  could  also  link  the  symbols  that 
refer  to  specific  objects  to  web  pages  that  describe 
these  objects,  where  available. 

8.4  Hierarchical  Refinements 

The  next  concept  from  the  CPR/BDI  ontology  ex¬ 
tends  the  representation  with  hierarchical  task  re¬ 
finements,  an  approach  to  AI  planning  that  has 
been  used  by  many  practical  planning  systems. 
This  is  because  the  standard  operating  procedures 
found  in  manuals  often  resemble  this  style  of  pro¬ 
cedural  knowledge.  From  a  technical  point  of  view, 
the  representation  is  as  for  operators,  namely,  a  set 
of  XML  element  tags  that  can  be  used  to  mark  up 
wiki  text  as  a  method  that  breaks  down  a  complex 
task  into  finder  grained  activities.  The  following  is 
an  example  of  such  a  refinement: 

<method  name="take-and-put"> 

<parameters> 

*  <var  name="c"  type="container"  />:  the 
container  which  is  moved  from  pile  to 
pile; 

*  <var  name="k"  type="crane"  />:  the 
crane  which  will  pick  up  and  put  down 
the  container; 

*  <var  name="l"  type="location"  />:  the 
location  at  which  all  this  takes  place; 

*  <var  name="po"  type="pile"  />:  the  pile 
from  which  the  topmost  container  is  to 
be  moved; 

*  <var  name="pd"  type="pile"  />:  the  pile 
to  which  the  container  is  to  be  moved 

*  <var  name="xo"  type="container"  />: 

the  container  on  which  the  container  to 
be  moved  is  currently; 

*  <var  name="xd"  type="container "  />:  the 
container  onto  which  the  container  to 
be  moved  will  be. 

</ parameter s> 

<accomplishes> 

<activity  type="move-top-container"> 
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Figure  8:  An  Action  rendered  in  the  Wiki 
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<parameters> 

*  <var  name="po"  />:  the  pile  from  which 
the  topmost  container  is  to  be  moved; 

*  <var  name="pd"  />:  the  pile  to  which 
the  container  is  to  be  moved. 

</parameters> 

</ activity> 

</ accomplishes> 

<preconditions> 

*  <atom> 

<rel  name="top"  /> 

<var  name="c"  /> 

<var  name="po"  /> 

</atom>:  the  container  must  be  at  the 
top  of  the  pile  from  which  it  is  to  be 
moved; 

*  <atom> 

<rel  name="on"  /> 

<var  name="c"  /> 

<var  name="xo"  /> 

</atom>  (used  to  bind  xo) ; 

*  <atom> 

<rel  name="attached"  /> 

<var  name="po"  /> 

<var  name="l"  /> 

</ atom> ; 

*  <atom> 

<rel  name="attached"  /> 

<var  name="pd"  /> 

<var  name="l"  /> 

</ atom> ; 

*  <atom> 

<rel  name="belong"  /> 

<var  name="k"  /> 

<var  name="l"  /> 

</atom>:  both  piles  and  the  crane  must 
be  at  the  same  location  (used  to  bind  1) ; 

*  <atom> 

<rel  name="top"  /> 

<var  name="xd"  /> 

<var  name="pd"  /> 

</atom>:  (used  to  bind  xd) . 
</preconditions> 

Note  that  there  is  no  precondition  that 
requires  the  crane  not  to  hold  a  container 
already . 

<steps> 


The  first  step  is  to  pick  up  the  container 
with  the  crane.  As  a  result  the  crane  will 
be  holding  the  container. 

<activity  type="take"  ref="take"> 
<parameters> 

<var  name="k"  />, 

<var  name="l"  />, 

<var  name="c"  />, 

<var  name="xo"  />, 

<var  name="po"  />. 

</ parameter s> 

</ activity> 

The  second  step  is  to  put  down  the 
container  on  the  destination  pile.  As  a 
result  the  crane  will  be  empty. 

<activity  type="put"  ref="put"> 
<parameters> 

<var  name="k"  />, 

<var  name="l"  />, 

<var  name="c"  />, 

<var  name="xd"  />, 

<var  name="pd"  />. 

</ parameter s> 

</ activity> 

</steps> 

<constraints> 

*  <atom> 

<rel  name="bef ore"  /> 

<object  name="take"  /> 

<object  name="put"  /> 

</atom>:  the  ordering  of  the  two  steps. 
</constraints> 

</method> 

The  description  of  a  method  or  refinement  is 
enclosed  in  a  method  element,  which  has  one  at¬ 
tribute,  the  name  of  the  method.  The  first  element 
inside  a  method  are  the  parameters,  which  are  ex¬ 
actly  the  same  as  for  operator  descriptions,  a  se¬ 
quence  of  variable  declarations. 

The  next  element  is  used  to  describe  what  ex¬ 
actly  this  method  accomplishes.  This  will  be  a  task 
marked  up  with  the  activity  element,  which,  at 
this  point,  has  only  one  attribute,  namely  the  name 
of  the  activity.  In  the  future,  this  could  be  used  as 
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a  reference  into  an  ontology  of  activities.  An  activ¬ 
ity  contains  a  list  of  parameters,  which  should  be 
variables  declared  for  the  method. 

The  preconditions  that  follow  look  exactly  like 
the  one  for  an  operator. 

Instead  of  effects,  however,  a  method  has  a  set 
of  steps  that  must  be  executed  in  order  to  accom¬ 
plish  the  task  for  this  method.  The  steps  are 
again  activities  that  consist  of  an  activity  ele¬ 
ment  that  contains  parameters.  The  difference  is 
that  the  activity  elements  here  also  contain  a  ref 
attribute  that  can  be  used  to  define  a  unique  refer¬ 
ence  name  for  this  activity  in  this  method. 

The  final  element  in  a  method  are  the  con¬ 
straints.  The  example  above  shows  just  one  con¬ 
straint  that  asserts  an  ordering  between  the  two 
activities  that  constitute  the  steps  of  this  method. 
The  exact  types  of  constraints  that  are  permitted 
depends  on  what  a  reasoning  engine,  e.g.  a  plan¬ 
ner,  can  handle.  As  the  wiki  simply  stores  these 
constraints  and  does  not  reason  over  them,  any  con¬ 
straint  can  be  added  to  the  marked  up  wiki  text. 
And,  of  course,  any  information  that  appears  im¬ 
portant  to  the  knowledge  engineer  but  does  not  fit 
into  the  tag  structure  can  be  added  as  plain  text 
and  will  not  be  lost. 

The  representation  of  the  methods  in  the 
database  requires  two  additional  tables  that  are  de¬ 
fined  below. 

create  table  mw_plan_activity  ( 
aid  int  unsigned  not  null, 
rid  int  unsigned  not  null, 
uref  varchar(64)  not  null, 
descr  varchar(255)  not  null, 
owntype  int  unsigned  not  null, 
ownid  int  unsigned  not  null, 

primary  key  (aid,  rid) 

); 

The  first  table  stores  the  activities  in  a  method. 
Mostly,  this  consists  of  the  user  defined  references 
for  steps  within  the  method  body,  and  a  textual  de¬ 
scription  containing  the  activity  name  and  its  argu¬ 
ments.  The  owner  of  an  activity  must  be  a  method, 
at  present. 

create  table  mw_plan_method  ( 
aid  int  unsigned  not  null, 


mid  int  unsigned  not  null, 
name  varchar(64)  not  null, 
task  varchar (255)  not  null, 
owntype  int  unsigned, 
ownid  int  unsigned, 

primary  key  (aid,  mid) 

) ; 

Having  seen  all  the  elements  and  structure  in  the 
sample  method  above,  it  is  perhaps  surprising  to 
see  the  simplicity  of  the  table  that  contains  the 
methods.  It  has  two  main  fields,  the  name  of  the 
method  and  the  activity  that  is  the  task  accom¬ 
plished  by  the  method.  All  other  elements  that  link 
into  a  method  specify  the  method  as  their  owner  in 
the  respective  tables. 

The  rendered  method  is  shown  in  figure  9. 

8.5  Classical  Planning  Domains 

Planning  domains  can  be  defined  in  the  MediaWiki 
extension,  but  consist  simply  of  a  named  set  of 
planning  operators  and  methods.  As  this  simply 
adds  one  XML  element  that  surrounds  the  other 
elements  described  above,  there  is  no  need  to  add 
a  lengthy  example  here. 

Domains  are  stored  in  their  own  table  in  the 
database  which  is  defined  as  follows: 

create  table  mw_plan_domain  ( 
aid  int  unsigned  not  null, 
did  int  unsigned  not  null, 
name  varchar (64)  not  null, 
owntype  int  unsigned, 
ownid  int  unsigned, 

primary  key  (aid,  did) 

); 

Again,  it  is  the  owner  field  in  the  various  ele¬ 
ments  in  a  domain  that  are  used  to  link  the  domain 
together.  The  only  descriptive  field  in  this  table  is 
the  name  of  the  domain,  which  is  used  to  define 
planning  problems. 

8.6  Classical  Planning  Problems 

Like  classical  planning  domains,  classical  planning 
problems  are  simply  aggregations  of  the  concepts 
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I  [J)  Planning:Move  -  LocalWiki 


Hierarchical  Task  Breakdown  (Methods) 


[edit] 


Method:  take-and-put 


Parameters  (7) 

■  9c  (type:  container) :  the  container  which  is  moved  from  pile  to  pile; 

■  ?k  (type:  crane) :  the  crane  which  will  pick  up  and  put  down  the  container; 

■  ?l  (type:  location) :  the  location  at  which  all  this  takes  place; 

■  ?po  (type:  pile) :  the  pile  from  which  the  topmost  container  is  to  be  moved; 

■  ?pd  (type:  pile) :  the  pile  to  which  the  container  is  to  be  moved 

■  ?xo  (type:  container) :  the  container  on  which  the  container  to  be  moved  is  currently; 

■  ?xd  (type:  container) :  the  the  container  onto  which  the  container  to  be  moved  will  be. 


Accomplishes  activity  type:  move-top-container 

Parameters  (2) 

■  ?po  :  the  pile  from  which  the  topmost  container  is  to  be  moved; 

■  ?pd  :  the  pile  to  which  the  container  is  to  be  moved. 


Preconditions  (6) 

■  (top  ?c  ?po  ):  the  container  must  be  at  the  top  of  the  pile  from  which  it  is  to  be  moved; 

■  (on  ?c  ?xo  )  (used  to  bind  xo); 

■  (attached  ?po  ?l); 

■  (attached  ?pd  ?1 ); 

■  (belong  ?k  91 ):  both  piles  and  the  crane  must  be  at  the  same  location  (used  to  bind  I); 

■  (top  ?xd  ?pd):  (used  to  bind  xd). 

Note  that  there  is  no  precondition  that  requires  the  crane  not  to  hold  a  container  already. 

Steps  in  method  (2) 

The  first  step  is  to  pick  up  the  container  with  the  crane.  As  a  result  the  crane  will  be  holding  the  container. 

Activity:  take  (ref:  take) 

Parameters  (5) 

7k.91.9c,  9xo  .  9po  . 

The  second  step  is  to  put  down  the  container  on  the  destination  pile.  As  a  result  the  crane  will  be  empty. 
Activity:  put  (ref:  put) 

Parameters  (5) 

9k  .  91  .  9c  .  9xd  .  9pd  . 


Associated  constraints  (1) 

■  (before  take  put ):  the  ordering  of  the  two  steps. 


Figure  9:  A  Refinement /Method  rendered  in  the  Wiki 
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listed  above.  A  planning  problem  contains  a  ref¬ 
erence  to  a  domain,  an  initial  state,  and  a  goal. 
The  domain  is  simply  an  attribute  of  the  problem 
and  uses  the  name  defined  in  the  domain  defini¬ 
tion.  Hence,  domain  names  must  be  unique  even 
across  articles.  The  initial  state  and  the  goal  are 
both  XML  elements  defined  in  the  extension,  each 
grouping  a  set  of  atoms  together.  Since  state  de¬ 
scriptions  tend  to  be  rather  lengthy,  the  following 
only  lists  the  beginning  of  the  definition  of  an  initial 
state: 

<state  ref="dwr-probleml"> 

First,  there  are  the  static  relations 
which  describe  the  topology  of  the  world 
and  the  immobile  objects  which  exist  in  it. 
In  short,  there  are  two  adjacent  location 
with  a  crane  and  two  piles  each. 

There  are  two  locations  that  are  adjacent 
to  each  other.  Note  that  the  symmetry  of 
the  adjacency  relation  has  to  be  made 
explicit : 

*  <atom> 

<rel  name=" adjacent"  /> 

<object  name="ll"  /> 

<object  name="12"  /> 

</ atom> ; 

*  <atom> 

<rel  name=" adjacent"  /> 

<object  name="12"  /> 

<object  name="ll"  /> 

</ atom> ; 

There  is  one  crane  at  each  of  the  two 
locations : 

*  <atom> 

<rel  name="belong"  /> 

<object  name="kl"  /> 

<object  name="ll"  /> 

</ atom> ; 

*  <atom> 

<rel  name="belong"  /> 

<object  name="k2"  /> 

<object  name="12"  /> 

</ atom> ; 


The  state  element  contains  all  the  atoms  the  de¬ 
fine  the  world  state.  An  optional  attribute  allows 
to  name  this  state  such  that  it  may  be  re-used  in 
a  different  context,  a  feature  which  is  not  used  at 
present.  In  a  classical  world  state  all  atoms  must  be 
positive,  and  they  are  simply  listed  here,  together 
with  plenty  of  commenting  text.  The  database  ta¬ 
ble  for  world  states  is  defined  as  follows: 

create  table  mw_plan_worldstate  ( 
aid  int  unsigned  not  null, 
sid  int  unsigned  not  null, 
uref  varchar(64), 
owntype  int  unsigned, 
ownid  int  unsigned, 

primary  key  (aid,  sid) 

) ; 

As  before,  the  way  atoms  are  groups  is  stored 
within  the  atoms,  which  are  in  the  conditions  table, 
where  the  owner  is  the  same  world  state.  Goals  are 
almost  identical  in  terms  of  their  representation, 
which  is  why  no  example  is  given  here.  The  only 
difference  is  that  atom  in  goals  may  be  negated, 
but  this  feature  is  not  used  in  the  example  used. 
The  page  that  is  generated  by  MediaWiki  which 
contains  the  state  (partially)  listed  above  is  shown 
in  figure  10. 

8.7  Beliefs,  Desires  and  Intentions 

The  mental  attitudes  of  the  BDI  paradigm  are 
again  relatively  simple  structures  that  are  not  very 
interesting  from  a  syntactical  point  of  view.  Be¬ 
liefs  are  currently  only  set  of  atoms  (like  in  a  world 
state)  that  are  associated  with  an  agent.  More  com¬ 
plex  beliefs  may  be  introduced  as  required.  De¬ 
sires  and  intentions  are  syntactically  identical  in 
that  they  relate  an  activity  (we  adopt  a  task-centric 
view)  to  an  agent. 

The  database  schema  for  beliefs  is  defined  as  fol¬ 
lows: 

create  table  mw_plan_belief  ( 
aid  int  unsigned  not  null, 
bid  int  unsigned  not  null, 
agent  varchar(64)  not  null, 
tpt  datetime  not  null, 
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|  [J]  Planning:Move  -  LocalWiki 


Classical  Planning  Problems 


[edit] 


Word  State  Description:  (ref:  dwr-probiemi) 

First,  there  are  the  static  relations  which  describe  the  topology  of  the  world  and  the  immobile  objects  which  exist  in  it.  In  short,  there  are  two  adjacent  location 
with  a  crane  and  two  piles  each. 

There  are  two  locations  that  are  adjacent  to  each  other.  Note  that  the  symmetry  of  the  adjacency  relation  has  to  be  made  explicit: 

■  (adjacent  11  12  ); 

■  (adjacent  12  11 ); 

There  is  one  crane  at  each  of  the  two  locations: 

■  (belong  kl  11); 

■  (belong  k2  12  ); 

Two  are  two  piles  for  storing  containers  at  each  location,  i.e.  there  are  four  piles  in  total: 

■  (attached  pi  11 ); 

■  (attached  ql  11 ); 

»  (attached  p2  12  ); 

■  (attached  q2  12  ); 

Then  there  are  the  dynamic  relations  that  will  change  as  actions  are  executed.  In  short,  there  is  one  robot  at  the  first  location.  Also  at  this  location  are  two  piles 
containing  a  stack  of  three  containers  each. 

The  first  pile  consists  of  containers  ca,  cb  and  cc,  where  cc  is  at  the  top  of  the  pile  and  ca  is  the  bottom  container,  which  sits  on  a  pallet: 

■  (in  ca  pi ); 

■  (in  cb  pi ); 

■  (in  cc  pi); 

■  (on  ca  pallet ); 

■  (on  cb  ca ); 

■  (on  cc  cb  ); 

The  second  pile  consists  of  containers  cd,  ce  and  cf ,  where  cf  is  at  the  top  of  the  pile  and  cd  is  the  bottom  container,  which  sits  on  a  pallet: 

■  (in  cd  pi ); 


i  (in  ce  pi ) 
i  (in  cf  pi ); 
i  (on  cd  pallet ); 
i  (on  ce  cd ); 
i  (on  cf  ce  ); 


Goal  Description: 

The  goal  in  this  problem  is  to  move  all  the  containers  to  the  two  piles  at  the  other  location,  two  containers  into  one  pile  and  four  into  the  other.  The  order  of  the 
containers  in  their  destination  piles  and  the  position  of  the  robot  is  not  specified. 

■  (in  ca  p2  ); 

■  (in  cb  q2  ); 

■  (in  cc  p2  ); 

■  (in  cd  q2  ); 

■  (in  ce  q2  ); 

■  (in  cf  q2  ); 

An  optimal  solution  plan  for  this  problem  contains  35  actions.  Since  there  are  a  number  of  actions  that  can  be  executed  in  parallel,  there  are  many  optimal  total 
order  plans. 


Figure  10:  A  Planning  Problem  rendered  in  the  Wiki 
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owntype  int  unsigned, 
ownid  int  unsigned, 

primary  key  (aid,  bid) 

); 

Apart  from  the  agent  that  holds  the  belief,  this 
may  also  include  a  time  point  at  which  the  agent 
holds  this  belief.  This  is  a  compromise  between 
having  no  times  associated  with  beliefs  and  having 
intervals  associated  with  them.  Whether  this  is  suf¬ 
ficient  really  depends  on  the  reasoning  engine  that 
will  use  this  information.  Desires  and  intentions 
are  very  similar  and  they  are  omitted  here. 

8.8  Agent  Capabilities 

The  final  concept  to  be  described  here  are  agent 
capabilities  which  are  used  in  many  frameworks  for 
multi-agent  planning.  Capabilities  can  be  seen  as 
planning  operators,  instances  of  which  can  be  as¬ 
signed  to  an  agent  that  has  the  capability  in  a  plan. 
They  can  also  be  compared  to  task  that  can  be  ac¬ 
complished  in  HTN  planning.  In  both  cases,  the 
representation  consists  of  a  symbol  representing  the 
name  of  the  activity  that  is  accomplished  with  some 
parameters  representing  the  objects  involved  in  ap¬ 
plying  the  capability.  An  example  of  a  capability 
representation  is  shown  in  the  following: 

Ccapability  agent="crane456a"> 

<accomplishes> 

<activity  type="move-top-container"> 
<parameters> 

*  <var  name="po"  />:  the  pile  from  which 
the  topmost  container  is  to  be  moved; 

*  <var  name="pd"  />:  the  pile  to  which 
the  container  is  to  be  moved. 

</parameters> 

</ activity> 

</ accomplishes> 

<constraints> 

*  <atom> 

<rel  name="attached"  /> 

<var  name="po"  /> 

<object  name="loc456"  /> 

</ atom> ; 

*  <atom> 


<rel  name="attached"  /> 

<var  name="pd"  /> 

<object  name="loc456"  /> 

</atom> ; 

</ constraints> 

</ capability> 

In  addition  to  the  activity  accomplished,  a  capa¬ 
bility  description  may  contain  constraints  on  the 
applicability  of  the  capability.  These  are  simi¬ 
lar  to  the  preconditions  associated  with  a  method. 
In  fact,  syntactically  they  are  the  same.  Cur¬ 
rently  these  conditions  are  limited  to  static  rela¬ 
tions  though,  i.e.  relations  that  do  not  change  over 
time,  such  as  the  topology  of  the  locations.  This 
means  capabilities  are  either  applicable,  or  they 
are  not.  there  is  no  way  to  make  them  applica¬ 
ble  in  a  different  situation.  The  intention  is  still  to 
have  agents  have  autonomy  and  be  able  to  decide 
whether  they  can  apply  a  given  capability,  depend¬ 
ing  on  many  factors.  The  constraints  can  be  used 
to  filter  out  many  plans  as  infeasible  though,  which 
saves  planning  effort. 

The  database  table  that  holds  the  capabilities  is 
defined  as  follows: 

create  table  mw_plan_capability  ( 
aid  int  unsigned  not  null, 
cid  int  unsigned  not  null, 
agent  varchar(64)  not  null, 
task  varchar (255)  not  null, 
owntype  int  unsigned, 
ownid  int  unsigned, 

primary  key  (aid,  cid) 

); 

The  constraints  on  a  capability  are  again  in  the 
conditions  and  have  the  capability  as  their  owner. 
The  capability  defined  in  the  example  above  is  ren¬ 
dered  in  figure  11. 

9  Domain  Features  to  Facil¬ 
itate  Knowledge  Engineer¬ 
ing 

Specifying  a  planning  domain  and  a  planning  prob¬ 
lem  in  a  formal  description  language  defines  a 
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Figure  11:  A  Capability  rendered  in  the  Wiki 


search  space  that  can  be  traversed  by  a  state- 
space  planner  to  find  a  solution  plan.  It  is  well 
known  that  this  specification  process,  also  known 
as  problem  formulation  [Russell  and  Norvig,  2003], 
is  essential  for  enabling  efficient  problem-solving 
though  search  [Amarel,  1968]. 

The  Planning  Domain  Definition  Language 
(pddl)  [Fox  and  Long,  2003]  has  become  a  de-facto 
standard  for  specifying  STRIPS-Iike  planning  do¬ 
mains  and  problems  with  various  extensions.  PDDL 
allows  for  the  specification  of  some  auxiliary  infor¬ 
mation  about  a  domain,  such  as  types,  but  this 
information  is  optional. 

9.1  Domain  Features 

In  this  paper  we  will  formally  define  four  domain 
features  that  can  be  used  to  assist  knowledge  engi¬ 
neers  during  the  problem  formulation  process,  i.e. 
the  authoring  of  a  planning  domain  which  defines 
the  state  space.  These  features  may  also  be  ex¬ 
ploited  by  a  planning  algorithm  to  speed  up  the 
search,  but  this  possibility  depends  on  the  actual 
planning  algorithm  used  and  will  not  be  evaluated 
in  this  paper.  The  features  defined  here  are:  do¬ 
main  types ,  relation  fluency ,  inconsistent  effects 
and  reversible  actions.  These  features  are  not  new, 
at  least  at  an  informal  level.  Their  specification 


is  either  already  part  of  pddl  or  could  easily  be 
added  to  the  language. 

The  values  these  features  take  for  a  given  do¬ 
main  can  also  be  computed  independent  of  their 
explicit  specification.  A  comparison  of  the  com¬ 
puted  features  to  the  ones  specified  in  the  formal 
domain  definition  can  then  be  used  to  validate  the 
formalization,  thus  supporting  the  domain  author 
in  producing  a  consistent  domain.  Applying  this 
approach  to  various  planning  domains  shows  that 
the  features  defined  here  can  be  used  to  identify 
certain  representational  problems. 

9.2  Related  Work 

Amongst  the  features  mentioned  above,  domain 
types  have  been  discussed  most  in  the  planning  lit¬ 
erature.  A  rigorous  method  for  problem  formula¬ 
tion  in  the  case  of  planning  domains  was  presented 
in  [McCluskey  and  Porteous,  1997].  In  the  sec¬ 
ond  step  of  their  methodology  types  are  extracted 
from  an  informal  description  of  a  planning  domain. 
Types  have  been  used  as  a  basic  domain  feature 
in  TIM  [Fox  and  Long,  1998].  Their  approach  ex¬ 
ploits  functional  equivalence  of  objects  to  derive  a 
hierarchical  type  structure.  The  difference  between 
this  approach  and  our  algorithm  will  be  explained 
in  the  relevant  section  below.  This  work  has  later 
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been  extended  to  infer  generic  types  such  as  mo¬ 
biles  and  resources  that  can  be  exploited  to  opti¬ 
mize  plan  search  [Coles  and  Smith,  2006]. 

The  distinction  between  rigid  and  fluent  relations 
[Ghallab  et  al.,  2004]  is  common  in  AI  planning 
and  will  be  discussed  only  briefly.  Inconsistent  ef¬ 
fects  of  different  actions  are  exploited  in  the  Graph- 
Plan  algorithm  [Blum  and  Furst,  1995]  to  define 
the  mutex  relation.  However,  this  is  applied  to 
pairs  of  actions  (i.e.  fully  ground  instances  of  op¬ 
erators)  rather  than  operators.  Reversible  actions, 
as  a  domain  feature,  are  not  related  to  regression 
of  goals,  meaning  this  feature  is  unrelated  to  the 
direction  of  search  (forward  from  the  initial  state 
or  regressing  backwards  from  the  goal).  The  re¬ 
versibility  of  actions  (or  operators)  does  not  appear 
to  feature  much  in  the  AI  planning  literature.  How¬ 
ever,  in  generic  search  problems  they  are  a  common 
technique  used  to  prune  search  trees  [Russell  and 
Norvig,  2003]. 

Preprocessing  of  planning  domains  is  a  technique 
that  has  been  used  to  speed  up  the  planning  pro¬ 
cess  [Dawson  and  Siklossy,  1977].  Perhaps  the  most 
common  preprocessing  step  is  the  translation  of 
the  STRIPS  (function-free,  first-order)  representa¬ 
tion  into  a  propositional  representation.  An  infor¬ 
mal  algorithm  for  this  is  described  in  [Ghallab  et 
al.,  2004,  section  2.6].  A  conceptual  flaw  in  this  al¬ 
gorithm  (highlighted  by  the  analysis  of  inconsistent 
effects)  will  be  briefly  discussed  in  the  conclusions 
of  this  paper. 

10  Type  Information 

Many  planning  domains  include  explicit  type  infor¬ 
mation.  In  pddl  the  :  typing  requirement  allows 
the  specification  of  typed  variables  in  predicate  and 
operator  declarations.  In  problem  specifications,  it 
allows  the  assignment  of  constants  or  objects  to 
types.  If  nothing  else,  typing  tends  to  greatly  in¬ 
crease  the  readability  of  a  planning  domain.  How¬ 
ever,  it  is  not  necessary  for  most  planning  algo¬ 
rithms  to  work. 

In  this  section  we  will  show  how  type  informa¬ 
tion  can  be  inferred  from  the  operator  descriptions 
in  the  planning  domain  definition.  If  the  planning 
domain  includes  explicit  type  information  the  in¬ 
ferred  types  can  be  used  to  perform  a  consistency 
check,  thus  functioning  as  a  knowledge  engineering 


tool.  In  any  case,  type  information  can  be  used 
to  simplify  parts  of  the  planning  process.  For  ex¬ 
ample,  if  the  planner  needs  to  propositionalize  the 
planning  domain,  type  information  can  be  used  to 
limit  the  number  of  possible  values  for  variables,  or 
a  ground  backward  searcher  may  use  this  informa¬ 
tion  to  similar  effect. 

The  formalism  that  follows  is  necessary  to  show 
that  the  derived  type  system  is  maximally  spe¬ 
cific  given  the  knowledge  provided  by  the  oper¬ 
ators,  that  is,  any  type  system  that  further  sub¬ 
divides  a  derived  type  must  necessarily  lead  to  a 
search  space  that  contains  type  inconsistent  states. 

10.1  Type  Consistency 

The  simplest  kind  of  type  system  often  used  in 
planning  is  one  in  which  the  set  of  all  constants 
C  used  in  the  planning  domain  and  problem  is  di¬ 
vided  into  disjoint  types  T.  That  is,  each  type  cor¬ 
responds  to  a  subset  of  all  constants  and  each  con¬ 
stant  belongs  to  exactly  one  type.  This  is  the  kind 
of  type  system  we  will  look  at  here. 

Definition  1  (type  partition)  A  type  parti¬ 
tion  V  is  a  tuple  ( C ,  T ,  r)  where: 

•  C  is  a  finite  set  of  n(C )  >  1  constant  symbols 
C  =  {ci, . . .  ,c„(C)}, 

•  T  is  a  set  of  n(T )  <  n(C )  types  T  = 
{ii,  •  •  • ,  tn(T)}> 

•  r  :  C  — >  T  is  a  function  defining  the  type  of  a 
given  constant. 

A  type  partition  divides  the  set  of  all  constants 
that  may  occur  in  a  planning  problem  into  a  set  of 
equivalence  classes.  The  availability  of  a  type  par¬ 
tition  can  be  used  to  limit  the  space  of  world  states 
that  may  be  searched  by  a  planner.  In  general,  a 
world  state  in  a  planning  domain  can  be  any  sub¬ 
set  of  the  powerset  of  the  set  of  ground  atoms  over 
predicates  P  with  arguments  from  C. 

Definition  2  (type  function)  Let  P  = 

{Pi, . . . ,  Pn(P)}  be  a  set  of  n(P)  predicate 
symbols  with  associated  arities  a(Pi)  and  let 
T  =  {ti, . . .  ,tn(r)}  be  a  set  of  types.  A 
type  function  for  predicates  is  a  function 
argp  :  P  x  N  — >  T 
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which,  for  a  given  predicate  symbol  Pi  and  ar¬ 
gument  number  1  <  k  <  a(Pi)  gives  the  type 
argp(Pi,k)  €  T  of  that  argument  position. 

This  is  the  kind  of  type  specification  we  find  in 
PDDL  domain  definitions  as  part  of  the  definition  of 
predicates  used  in  the  domain,  provided  that  the 
typing  extension  of  pddl  is  used.  The  type  func¬ 
tion  is  defined  by  enumerating  the  types  for  all  the 
arguments  of  each  predicate. 

Definition  3  (type  consistency)  Let  ( C ,  T,  r) 

be  a  type  partition.  Let  Pi  £  P  be  a  predicate  sym¬ 
bol  and  let  c±, . . . ,  ca(pi)  £  C  be  constant  symbols. 
The  ground  first-order  atom  Pj(ci, . . . ,  c0(po)  is 
type  consistent  iff  r(ck)  =  argp(Pi,k).  A  world 
state  is  type  consistent  iff  all  its  members  are 
type  consistent. 

Thus,  for  a  given  predicate  T\  there  are  \C\a'-Pi> 
possible  ground  instances  that  may  occur  in  world 
states.  Clearly,  the  set  of  type  consistent  world 
states  is  a  subset  of  the  set  of  all  world  states.  The 
availability  of  a  set  of  types  can  also  be  used  to 
limit  the  actions  considered  by  a  planner. 

Definition  4  (type  function)  Let  O  = 

{Oi, . . . ,  On(o)}  be  a  set  of  n(0)  operator 
names  with  associated  arities  a(0;)  and  let 
T  =  {ti, . . . ,  tncr)}  be  a  set  of  types.  A 
type  function  for  operators  is  a  function 
argo  :OxR-tT 

which,  for  a  given  operator  symbol  Oi  and  ar¬ 
gument  number  1  <  k  <  a(Oi )  gives  the  type 
argo(Oi,  k)  £  T  of  that  argument  position. 

Again,  this  is  exactly  the  kind  of  type  specifica¬ 
tion  that  may  be  provided  in  PDDL  where  the  func¬ 
tion  is  defined  by  enumeration  of  all  the  arguments 
with  their  types  for  each  operator  definition. 

Definition  5  (type  consistency)  Let  ( C ,  T,  r) 

be  a  type  partition.  Let  Oj(i>i,  ■  ■  • ,  ^a(Oi)) 
be  a  strips  operator  defined  over  variables 
vi, . . . ,  va(Pi)  with  preconditions  precs(Oi) 
and  effects  effects(Oi),  where  each  precondi¬ 
tion/effect  has  the  form  Pj(vpjt%, . . . ,  tfp.,Q(p)) 
or  ^Pjivp^.. . . ,  Wpi)0(F,))  f°r  some  predicate 
Pj  £  P.  The  operator  Oi  is  type  consistent  iff: 

•  all  the  operator  variables  v± ,...,va(Oi)  are 
mentioned  in  the  positive  preconditions  of  the 
operator,  and 


•  if  Vk  =  vp.y,  i.e.  the  kth  argument  variable  of 
the  operator  is  the  same  as  the  Ith  argument 
variable  of  a  precondition  or  effect,  then  the 
types  must  also  be  the  same:  argo(Oi,  k)  = 
argP{Pj,l). 

The  first  condition  is  often  required  only  im¬ 
plicitly  (see  [Ghallab  et  al,  2004,  chapter  4])  to 
avoid  the  complication  of  “lifted”  search  in  forward 
search.  We  will  use  this  condition  shortly  to  show 
that  a  type  consistent  system  is  closed. 

Given  a  type  partition  (C,  T,  r)  and  type  func¬ 
tions  argp  and  argo,  we  can  define  a  most  gen¬ 
eral  state-transition  system  over  all  type  consistent 
states  as  follows: 

Definition  6  (state-transition  system  E*) 

Let  ( C ,  T,  r)  be  a  type  partition.  Let 
P  =  {Pi, . . . ,  P„(p)}  be  a  set  of  predicate 
symbols  with  associated  type  function  argp  and  let 
O  =  {Oi On(o)}  be  a  set  of  type  consistent 
operators.  Then  S*  =  (S'*,  A*, 7)  is  a  (restricted) 
state-transition  system,  where: 

•  S*  is  the  powerset  of  the  set  of  all  type  consis¬ 
tent  ground  atoms  with  predicates  from  P  and 
arguments  from  C, 

•  A*  is  the  set  of  all  (type  consistent)  ground 
instances  of  operators  from  O ,  and 

•  7  is  the  usual  state  transition  function  for 
STRIPS  actions:  7 (s,a)  =  (s—  effects-  (a))U 
effects+(a)  iff  action  a  is  applicable  in  state 
s1. 

This  state-transition  system  forms  a  super¬ 
system  to  a  state-transition  system  defined  by  a 
planning  problem  containing  a  type  consistent  ini¬ 
tial  state,  and  a  set  of  type  consistent  operator  def¬ 
initions,  in  the  sense  that  the  states  of  that  system 
(the  reachable  states  from  the  initial  states)  must 
be  a  subset  of  S*  and  the  actions  must  be  a  subset 
A* .  It  is  therefore  interesting  to  observe  that  S*  is 
closed: 

Proposition  1  (closed  E*)  Let  s  £  S*  be  a  type 
consistent  state,  i.e.  a  type  consistent  set  of  ground 
atoms.  Let  a  £  A*  be  a  type  consistent  action  that. 

1  See  the  definition  of  a  STRIPS  operator  in  [Ghallab  et 
al.,  2004,  page  28]  and  the  discussion  of  inconsistent  effects 
below. 
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is  applicable  in  s.  Then  the  successor  state  7 (s,a) 
is  a  type  consistent  state  in  S* . 

To  show  that  the  above  is  true,  we  need  to  show 
that  every  atom  in  7 (s,a)  is  type  consistent.  Each 
atom  in  7 (s,  a)  was  either  in  the  previous  state,  s, 
in  which  case  it  was  type  consistent  by  definition, 
or  it  was  added  as  a  positive  effect.  Since  the  action 
is  an  applicable  instance  of  a  type  consistent  oper¬ 
ator  Oi  there  must  be  a  substitution  a  such  that 
cr(precs  +  (Oi))  C  s.  Furthermore,  this  substitution 
grounds  every  operator  variable  because  type  con¬ 
sistency  requires  all  of  them  to  occur  in  the  positive 
preconditions.  Given  the  type  consistency  of  s,  all 
arguments  in  a(precs+  (Oi))  must  agree  with  argp. 
Given  the  type  consistency  of  Oi ,  all  arguments  of  a 
must  agree  with  argo ,  and  therefore  so  must  the  ef¬ 
fects  a  (effects  (Oi)).  Hence,  all  positive  effects  are 
type  consistent,  meaning  every  element  of  j(s,  a) 
must  be  type  consistent.  ■ 

10.2  Derived  Types 

The  above  definitions  assume  that  there  is  an  un¬ 
derlying  type  system  that  has  been  used  to  define 
the  planning  domain  and  problems  in  a  consistent 
fashion.  We  shall  continue  to  assume  that  such  a 
type  system  exists,  but  it  may  not  have  been  explic¬ 
itly  specified  in  the  PDDL  definition  of  the  domain. 
We  shall  now  define  a  type  system  that  is  derived 
from  the  operator  descriptions  in  the  planning  do¬ 
main. 

Definition  7  (type  name)  Let  O  = 

{Oi, . . . ,  On(Q)}  be  a  set  of  STRIPS  operators. 
Let  P  be  the  set  of  all  the  predicate  symbols  used 
in  all  the  operators.  A  type  name  is  a  pair 
( N ,  k)  G  (P  U  O)  x  N. 

A  type  name  can  be  used  to  refer  to  a  type  in 
a  derived  type  system.  There  usually  are  multi¬ 
ple  names  to  refer  to  the  same  type.  The  basic 
idea  behind  the  derived  types  is  to  partition  the 
set  of  all  type  names  into  equivalence  classes,  and 
then  assign  constants  used  in  a  planning  problem 
to  different  equivalence  classes,  thus  treating  each 
equivalence  class  as  a  type. 

Definition  8  (O-type)  Let  O  =  {Oi, . . . ,  On(Q)} 
be  a  set  of  STRIPS  operators  over  operator  vari¬ 
ables  Vi, . . .  ,va(Oi)  conds(Oi)  =  precs(Oi)  U 


effects(Oi)  and  all  operator  variables  mentioned  in 
the  positive  preconditions.  Let  P  be  the  set  of  all 
the  predicate  symbols  used  in  all  the  operators.  An 
O-type  is  a  set  of  type  names.  Two  type  names 
(Ni,i\)  and  (N2,i2)  «re  in  the  same  O-type,  de¬ 
noted  (ATi,*i)  =0  <JV2)*2>,  iff  one  of  the  following 
holds: 


•  Ni(vitl,  .  .  .  ,  Vi  a^))  is 

an 

oper- 

ator  with  precondition 

or 

effect 

N2(v 2,i,..  ■  ,t>2,a(jv2))  Gconds(Ni) 

which 

share  a  specific  variable:  Vi^x  = 

V2  ,i2, 

•  N2(v2,i,...,v2,a(N2))  is 

an 

oper- 

ator  with  precondition 

or 

effect 

N1(v1> !,  •  •  •  ,f1,a(AT1))  £conds(N2) 

which 

share  a  specific  variable:  v\  ^  =  v2  ,i2,  or 

•  there  is  a  type  name  ( N,j )  such  that  ( N,j )  =Q 
(Ni,ii)  and  ( N,j )  =Q  (. N2,i2 ). 

Definition  9  (O-type  partition)  Let  (si,g,0) 
be  a  STRIPS  planning  problem.  Let  C  be  the  set  of 
all  constants  used  in  s,;.  Let  T  =  {ti, . . .  ,tnrr)} 
be  the  set  of  O-types  derived  from  the  operators  in 
O.  Then  we  can  define  the  function  r  :  C  — >  T  as 
follows: 

t(c)  =  L  :  \/R(c 1, . . . ,  ca{R))  G  Si  : 

(Cj  —  c)  (P,  j)  G  ti 

Note  that  r(c)  is  not  necessarily  well-defined  for 
every  constant  mentioned  in  the  initial  state,  e.g.  if 
a  constant  is  used  in  two  relations  that  would  indi¬ 
cate  different  derived  types  (which  rely  only  on  the 
operator  descriptions) .  In  this  case  the  O-type  par¬ 
tition  cannot  be  used  as  defined  above.  However,  if 
appropriate  unions  of  O-types  are  taken  then  this 
results  in  a  new  type  partition  for  which  r(c)  is 
defined.  In  the  worst  case  this  will  lead  to  a  type 
partition  consisting  of  a  single  type.  Given  that  this 
approach  is  always  possible,  we  shall  now  assume 
that  r(c)  is  always  defined. 

Definition  10  Let  T  =  be  the  set 

of  O-types  for  a  given  set  of  operators  O  and  let 
P  =  {Pi, . . . ,  P„(p)}  be  the  predicates  that  occur 
on  operators  from  O.  We  can  easily  define  type 
functions  argp  and  argo  as  follows: 

argp(Pi,k)  =  ti  :  (Pi,k)  G  ti  and 
argo(Oi ,  k)  =  U  :  ( 0* ,  k)  G  U 
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Proposition  2  Let  ( Si,g,0 )  be  a  strips  planning 
problem  and  let  ( C ,  T,  r)  &e  </ie  O-type  partition  de¬ 
rived  from  this  problem.  Then  every  state  that  is 
reachable  from  the  initial  state  s,  is  type  consistent. 

To  show  this  we  first  show  that  the  initial  state 
is  type  consistent.  Since  the  definition  of  r  is  based 
on  the  argument  positions  in  which  they  occur  in 
the  initial  state,  this  follows  trivially. 

Next  we  need  to  show  that  every  action  that  is 
an  instance  of  an  operator  in  O  is  type  consistent. 
All  operator  variables  must  be  mentioned  in  the 
positive  preconditions  according  to  the  definition  of 
an  O-type.  Furthermore,  if  a  precondition  or  effect 
share  a  variable  with  the  operator,  these  must  have 
the  same  type  since  =o  puts  them  into  the  same 
equivalence  class. 

Finally  we  can  show  that,  if  action  a  is  applica¬ 
ble  in  a  type  consistent  state  s,  the  resulting  state 
j(s,a)  must  also  be  type  consistent.  Every  atom 
must  come  either  from  s  in  which  case  it  must  be 
type  consistent,  or  it  comes  from  a  positive  effect, 
which,  given  the  type  consistency  of  a  means  it 
must  also  be  type  consistent.  ■ 

This  shows  that  the  type  system  derived  from 
the  operator  definitions  is  indeed  useful  as  it  cre¬ 
ates  a  state  space  of  type  consistent  states.  How¬ 
ever,  the  question  that  remains  is  whether  it  is  the 
best  or  even  only  type  system.  Clearly,  there  may 
be  other  type  systems  that  give  us  type  consistent 
state  space.  The  system  that  consists  just  of  a  sin¬ 
gle  type  is  a  trivial  example.  A  better  type  system 
would  divide  the  set  of  constants  into  more  types 
though,  as  this  reduces  the  size  of  a  type  consistent 
state  space.  We  will  now  show  that  the  above  type 
system  is  maximally  specific  given  the  knowledge 
provided  by  the  operators. 

Theorem  1  Let  ( Si,g,0 )  be  a  strips  planning 
problem  and  let  ( C ,  T,  r)  be  the  O-type  partition  de¬ 
rived  from  this  problem.  If  two  constants  c±  and  c 2 
have  the  same  type  r(ci)  =  r(c2)  then  they  must 
have  the  same  type  in  every  type  partition  that  cre¬ 
ates  a  type  consistent  search  space. 

The  first  step  towards  showing  that  the  above 
holds  is  the  insight  that  operators  can  be  used 
to  constrain  types  in  both  directions,  forward  and 
backward.  If  an  operator  variable  ty  appears  in  a 
precondition  and  an  effect,  then  the  type  of  the  po¬ 
sition  of  the  predicate  in  the  effect  must  be  subset 


of  the  type  of  the  position  in  the  precondition  or 
the  application  of  the  operator  may  lead  to  a  state 
that  is  not  type  consistent.  Since  types  are  defined 
by  an  equivalence  relation,  however,  the  two  types 
must  actually  be  the  same  type.  Hence  the  type  in 
the  effect  also  constrains  the  type  in  the  precondi¬ 
tion. 

Now,  for  two  type  names  to  be  in  the 
same  O-type,  there  must  be  a  connecting  chain 
( RqOiRi  . . .  OnRn )  of  alternating  first  order  liter¬ 
als  and  operators  such  that  R,-\  and  Ri  are  condi¬ 
tions  of  Oi  which  share  an  operator  variable  as  the 
ji-  ith  and  j,tli  argument  respectively.  The  vari¬ 
able  that  is  shared  may  vary  along  the  chain.  For 
each  step  along  the  chain,  if  a  constant  may  occur 
in  the  ji- ith  position  in  it  may  also  occur 

in  the  j,th  position  in  Ri.  Thus,  there  may  be  two 
type  consistent  states  that  are  connected  by  Oj  and 
which  contain  instances  of  Ri- \  and  Ri.  Since  both 
states  are  type  consistent,  both  instances  must  be 
type  consistent,  too. 

Now  let  us  assume  that  ci  appears  as  joth  argu¬ 
ment  in  Rq  and  let  C2  appears  as  jn th  argument  in 
Rn.  Furthermore,  let  us  assume  these  exists  a  type 
partition  that  assigns  c\  and  C2  to  different  types. 
Since  c\  is  the  joth  argument  in  Rq  there  may  be 
another  state  in  which  c\  appears  as  jnth  argument 
in  Rn.  Thus  it  appears  in  the  same  position  of  the 
same  predicate  as  C2,  which  means  it  must  have  the 
same  type  to  be  type  consistent.  ■ 

10.3  An  Efficient  Algorithm 

The  algorithm  to  derive  domain  types  td  treats 
types  as  sets  of  predicate  and  argument-number 
pairs.  That  is  td  C  2PxN.  Each  domain  type  td 
corresponds  to  exactly  one  type  t  £  T.  The  only 
argument  taken  by  the  algorithm  is  the  set  of  op¬ 
erator  definitions  O. 
function  extract-types (O) 
pTypes  <—  0 
vTypes  <—  0 
for  every  op  £  O  do 

extract-types(op,  pTypes,  vTypes) 
return  pTypes 


The  variable  pTypes  contains  the  O-types  that 
have  been  discovered  so  far.  Initially  there  are  no 
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O- types  and  the  set  is  empty.  vTypes  is  a  set  of 
pairs  of  variables  (used  in  operator  definitions)  and 
O-types,  best  implemented  as  a  map  and  also  ini¬ 
tially  empty.  The  procedure  then  analyzes  each 
operator  in  the  given  set,  thereby  building  up  the 
type  system  incrementally. 

function  extract-types {op, pTypes,  vTypes) 
for  every  p  £  pre(op)  U  eff(op )  do 

for  i  =  1  to  a(p)  do 
t 


the  variable  and  the  type  for  the  predicate-position 

combination  is  the  same.  Otherwise  we  replace 

the  two  sets  representing  the  (previously  different) 

types  in  pTypes  with  a  new  type  that  is  the  union 

of  the  two  sets.  Also  we  need  to  update  the  pairs 

in  vTypes  to  ensure  that  keys  that  previously  had 

one  of  the  now  removed  types  as  value  will  now  get 

the  new  type  as  their  new  value. 

It  is  easy  to  see  that  the  algorithm  runs  in  poly- 

,  „  /  7 /  \  -\  ,  nomial  time.  Furthermore,  the  analysis  performed 

Pi  —  td  £  pTypes  :  {rel(p),i)  £  td  , 

/  ,  ,  ,  „  4,  ,  , .  ,  ,  ,by  the  algorithm  uses  only  the  operator  descrip- 

{v,tv}  vt  £  vTypes  :  3td  :  vt  =  {arg{i,p),td)J_  _  °  A _ A  _ 

if  undef((v,tv))  do 


if  undef(tpi)  do 
tPi  <-  {(rel(p),i)} 
pTypes  4-  pTypes  U  tpi 
vTypes  <-  vTypes  U  (arg(i,p),tpi) 

else 

if  undef(tpi)  do 

tv  <—  tv  U  {(rel(p),i)} 

else 

merge- types (tv,  tpi, pTypes,  vTypes) 


The  analysis  of  a  given  operator  goes  through 
every  precondition  and  effect  of  the  operator,  look¬ 
ing  at  every  argument  position  in  turn.  The  next 
steps  of  the  algorithm  depend  on  whether  the 
predicate-position  combination  has  been  used  be¬ 
fore  (in  which  case  it  will  appear  in  the  pTypes ) 
and  whether  the  variable  at  that  position  has  been 
used  before  (in  which  case  it  will  be  a  key  in  the 
vTypes).  If  only  one  or  neither  have  been  used,  the 
algorithm  simply  adds  the  relevant  elements  to  the 
pTypes  and  the  vTypes.  If  both  have  been  used  it 
may  be  necessary  to  merge  the  respective  O-types. 

function  merge-types(fi,  t2, pTypes,  vTypes) 
if  t\  =  t'2  do 

return 

pTypes  <-  pTypes  -  {h,t2} 

tnew  *  t\  U  t‘2 

pTypes  <-  pTypes  U  {tnew} 
for  every  (v,tv)  £  vTypes  do 
if  (tv  =  ti)  V  (tv  =  t2)  do 


vTypes  4—  vTypes  —  (v,tv) 
vTypes  4-  vTypes  +  (v,  tnew ) 


Of  course,  no  action  is  required  if  the  type  of 


'tions,  and  thus  its  run  time  does  not  depend  on 
the  problem  size. 

This  algorithm  shares  the  input  with  TIM  [Fox 
and  Long,  1998],  namely  the  operator  specifica¬ 
tions.  Both  algorithms  use  the  argument  positions 
in  which  parameters  occur  in  preconditions  and  ef¬ 
fects  as  the  basis  for  their  analysis.  TIM  uses  this 
information  to  construct  a  set  of  finite  state  ma¬ 
chines  to  model  transitions  of  objects,  whereas  our 
algorithm  builds  the  equivalence  classes  directly. 
The  result  produced  by  TIM  is  a  hierarchical  type 
system  that  is  used  to  derive  state  invariants.  In 
contrast,  the  type  system  derived  by  our  algorithm 
is  flat,  meaning  it  may  be  less  discriminating  than 
the  structure  derived  by  TIM.  However,  we  could 
show  that  the  types  derived  by  our  algorithm  are 
maximally  specific  for  given  operator  descriptions. 
In  addition,  a  flat  type  system  can  be  used  to  enrich 
the  operator  definitions  explicitly  by  simply  adding 
unary  predicates  as  type  preconditions. 

10.4  Evaluation 

To  evaluate  the  algorithm  we  have  applied  it  to  a 
small  number  of  planning  domains.  To  avoid  any 
bias  we  used  only  planning  domains  that  were  avail¬ 
able  from  third  parties,  mostly  from  the  interna¬ 
tional  planning  competition.  Since  the  algorithm 
works  on  domains  and  the  results  have  to  be  in¬ 
terpreted  manually  only  a  limited  number  of  ex¬ 
periments  was  possible.  Random  domains  are  not 
suitable  as  they  cannot  be  expected  to  encode  an 
implicit  type  system.  The  algorithm  has  been  used 
on  random  domains,  but  this  did  not  result  in  any 
useful  insights. 

A  planning  domain  on  which  the  algorithm  has 
been  used  is  the  DWR  domain  [Ghallab  et  al, 
2004].  In  this  domain  types  are  defined  explicitly, 
so  it  was  possible  to  verify  consistency  with  the 
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given  types.  The  algorithm  produced  the  following, 
listing  the  argument  positions  in  predicates  where 
they  are  used  (the  pTypes): 

type:  [loaded-0,  unloaded-0,  at-0] 

type:  [attached-O,  top-1,  in-1] 

type:  [occupied-0,  attached-1,  belong-1, 

adjacent-1,  adjacent-O,  at-1] 
type:  [belong-0,  holding-0,  empty-0] 
type:  [loaded-1,  holding-1,  on-1,  on-0, 

in-0,  top-0] 

The  first  type  states  that  it  is  used  as  the  first  ar¬ 
gument  in  the  loaded,  unloaded  and  at  predicate. 
This  corresponds  exactly  to  the  robot  type  in  the 
PDDL  specification  of  the  domain.  Similarly,  the 
other  types  correspond  to  pile,  location,  crane 
and  container,  in  this  order.  The  main  difference 
is  that  the  derived  types  do  not  have  intelligible 
names. 

The  other  domains  that  were  used  for  testing  did 
not  come  with  type  information  specified  in  the 
same  way  as  the  DWR  domain.  However,  they 
all  use  unary  predicates  to  add  type  information 
to  the  preconditions  (but  not  every  unary  predi¬ 
cate  is  a  type).  The  domains  used  are  the  follow¬ 
ing  strips  domains  from  the  international  plan¬ 
ning  competition:  movie,  gripper,  logistics, 
mystery,  mprime  and  grid.  The  algorithm  derives 
between  3  and  5  types  for  each  of  these  domains 
which  appears  consistent  with  what  the  domain  au¬ 
thors  had  in  mind.  The  only  domain  that  stands 
out  is  the  first,  in  which  each  predicate  has  its  own 
type.  However  this  appears  to  be  appropriate  for 
this  very  simple  domain. 

11  Static  and  Fluent  Rela¬ 
tions 

Another  domain  feature  that  is  useful  for  the  analy¬ 
sis  of  planning  domains  concerns  the  relations  that 
are  used  in  the  definition  of  the  operators.  The  set 
of  predicates  used  here  can  be  divided  into  static  (or 
rigid)  relations  and  fluent  (or  dynamic)  relations, 
depending  on  whether  atoms  using  this  predicate 
can  change  their  truth  value  from  state  to  state. 

Definition  11  (static/fluent  relation)  Let 

O  =  {O i, . .  • ,  On(0)}  be  a  set  °f  operators  and  let 


P  =  {Pi, . . . ,  Pn(p)}  be  a  set  of  all  the  predicate 
symbols  that  occur  in  these  operators.  A  predicate 
Pi  £  P  is  fluent  iff  there  is  an  operator  Oj  £  O 
that  has  an  effect  that  uses  the  predicate  Pi. 
Otherwise  the  predicate  is  static. 

The  algorithm  for  computing  the  sets  of  fluent 
and  static  predicate  symbols  is  trivial  and  hence, 
we  will  not  list  it  here. 

There  are  at  least  two  ways  in  which  this  infor¬ 
mation  can  be  used  in  the  validation  of  planning 
problems.  Firstly,  if  the  domain  definition  language 
allowed  the  domain  author  to  specify  whether  a  re¬ 
lation  is  static  or  fluent  then  this  could  be  verified 
when  the  domain  is  parsed.  This  might  highlight 
problems  with  the  domain.  Secondly,  in  a  planning 
problem  that  uses  additional  relations  these  could 
be  highlighted  or  simply  removed  from  the  initial 
state. 

The  computation  of  static  and  fluent  relations 
has  been  tested  on  the  same  domains  as  the  derived 
types.  As  is  to  be  expected,  nothing  interesting  can 
be  learned  from  this  experiment. 

12  Inconsistent  Effects 

In  a  STRiPS-style  operator  definition  the  effects  are 
specified  as  and  add-  and  delete-lists  consisting  of 
a  set  of  (function-free)  first-order  atoms,  or  a  set 
of  first-order  literals  where  positive  elements  corre¬ 
spond  to  the  add-list  and  negative  elements  corre¬ 
spond  to  the  delete-list.  Normally,  the  definition 
of  an  operator  permits  potentially  inconsistent  ef¬ 
fects,  i.e.  a  positive  and  a  negative  effect  may  be 
complement  ary. 

12.1  Operators 

Definition  12  (potential  inconsistency)  Let 

O  be  a  planning  operator  with  positive  effects 
ei’  •  ■  •  >  en(ep)  and  negative  effects  ef, . . . ,  e”(en), 
where  each  positive /negative  effect  is  a  first-order 
atom.  O  has  potentially  inconsistent  effects 
iff  O  has  a  positive  effect  ef  and  a  negative  effect 
e”  for  which  there  exists  a  substitution  a  such  that 

a(ei)  =  o-(e"). 

It  is  fairly  common  for  planning  domains  to  de¬ 
fine  operators  with  potentially  inconsistent  effects. 
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For  example,  the  move  operator  in  the  DWR  do¬ 
main  is  defined  as  follows: 

( : action  move 

:parameters  (?r  ?fr  ?to) 

: precondition  (and  (adjacent  ?fr  ?to) 

(at  ?r  ?fr)  (not  (occupied  ?to))) 

:  effect  (and  (at  ?r  ?to)  (occupied  ?to) 

(not  (occupied  ?fr))  (not  (at  ?r  ?fr)))) 

This  operator  has  a  positive  effect  (at  ?r  ?to) 
and  a  negative  effect  (at  ?r  ?fr).  These  two  ef¬ 
fects  are  unifiable  and  represent  a  potential  incon¬ 
sistency.  Since  this  is  a  common  feature  in  plan¬ 
ning  domains  there  is  no  need  to  raise  this  to  the 
domain  author.  Effects  that  are  necessarily  incon¬ 
sistent  may  be  more  critical. 

Definition  13  (necessary  inconsistency) 

Let  O  be  a  planning  operator  with  positive 
effects  Ep  —  {ef, . . . ,  e^,ePA  and  negative 
effects  En  =  {e™, . . . ,  e”(e„)}>  where  each  pos¬ 
itive/negative  effect  is  a  first-order  atom.  O  has 
necessarily  inconsistent  effects  iff  O  has  a 
positive  effect  e?  and  a  negative  effect  e "  such  that 


None  of  the  domains  used  in  the  experi¬ 
ments  above  specified  an  operator  with  nec¬ 
essarily  inconsistent  effects.  Given  the  def¬ 
inition  of  the  state-transition  function  for 
strips  operators  [Ghallab  et  al.,  2004]  as 
7 (s,  a)  =  (s  -  En)  U  Ep 

it  should  be  clear  that  the  negative  effect  e"  can 
be  omitted  from  the  operator  description  without 
changing  the  set  of  reachable  states.  If  e"  ^  s 
then  its  removal  from  s  will  not  change  s,  and  the 
addition  of  e?  ensures  that  e"  G  7 (s,a)  because 
=  e™.  If  e"  €  s  it  will  be  removed  in  7 (s,a), 
but  it  will  subsequently  be  re-added.  Thus,  the 
presence  of  the  negative  effect  does  not  change  the 
range  of  the  state-transition  function. 

From  a  knowledge  engineering  perspective  this 
means  that  an  operator  with  necessarily  incon¬ 
sistent  effects  indicates  a  problem  and  should  be 
raised  to  the  domain  author.  However,  this  is  only 
true  for  simple  strips  operators  where  actions  are 
instantaneous  and  thus,  all  effects  happen  simulta¬ 
neously.  If  effects  are  permitted  at  different  time 
points  then  only  those  that  are  necessarily  incon¬ 
sistent  at  the  same  time  point  must  be  considered 
a  problem. 


12.2  Actions 


Since  actions  are  ground  instances  of  operators, 
there  is  no  need  to  distinguish  between  necessar¬ 
ily  and  potentially  inconsistent  effects.  All  effects 
must  be  ground  for  actions  and  therefore  incon¬ 
sistent  effects  are  always  necessarily  inconsistent. 
Even  if  necessarily  inconsistent  operators  are  not 
permitted  in  a  domain,  actions  with  inconsistent  ef¬ 
fects  may  still  occur  as  instances  of  operators  with 
potentially  inconsistent  effects. 

Whether  it  is  desirable  for  the  planner  to  con¬ 
sider  such  actions  depends  on  the  other  effects  of 
the  action.  For  example,  in  the  DWR  domain  no 
action  with  inconsistent  effects  needs  to  be  consid¬ 
ered.  However,  if  an  action  has  side  effects  then  it 
may  make  sense  to  permit  such  actions.  For  exam¬ 
ple,  circling  an  aircraft  in  a  holding  pattern  does 
not  change  the  location  of  the  aircraft,  but  it  does 
reduce  the  fuel  level.  If  such  side  effects  are  impor¬ 
tant  actions  with  inconsistent  effects  may  need  to 
be  permitted.  And,  of  course,  every  action  has  the 
side  effect  of  taking  up  a  step  in  a  plan. 

If  actions  with  inconsistent  effects  are  considered 
by  the  planner,  this  may  lead  to  further  complica¬ 
tions.  This  is  because  the  definition  of  the  state- 
transition  function  first  subtracts  negative  effects 
from  a  state  and  then  adds  positive  effects.  For 
actions  that  have  no  inconsistent  effects  this  order 
is  irrelevant.  However,  if  actions  with  inconsistent 
effects  are  permitted  the  result  may  be  surprising. 
For  example,  returning  to  the  move  operator  in  the 
DWR  domain,  this  has  been  defined  with  a  pos¬ 
itive  effect  (occupied  ?to)  and  a  negative  effect 
(occupied  ?fr).  Thus,  the  action  (move  r  loc 
loc)  will  result  in  a  state  in  which  (occupied  loc) 
holds.  Now  suppose  the  domain  had  been  defined 
using  the  predicate  free  instead  of  occupied.  In 
this  case  the  result  of  (move  r  loc  loc)  would 
result  in  a  state  in  which  (free  loc)  holds.  This 
problem  occurs  only  with  inconsistent  effects. 

None  of  the  domains  used  in  the  tests  above 
require  actions  with  inconsistent  effects  and  thus, 
they  can  be  ignored  by  the  planner.  The  following 
algorithm  can  be  used  to  find  the  applicable  actions 
(without  inconsistent  effects)  in  a  given  state. 
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function  addApplicables(A,  o,p,  a,  s) 
if  not  empty(p+)  then 
let  pnext  G  p 
for  every  sp  G  s  do 
a'  4-  unify (a(pnext),  sp) 
if  valid(cr')  then 

adclApplicables(A,  o,p  —  pnext.  ,  o7,  s) 

else 

for  every  pnext  G  p~  do 

if  falsifies ( s,  cr(pnext))  then  return 
for  every  ep  G  effects+(o)  do 
for  every  en  G  effects- (o)  do 

if  ep  =  en  then  return 

A  <—  A  +  cr(o) 

The  algorithm  adds  all  instances  of  operator  o 
that  are  applicable  in  state  s  to  the  set  of  actions 
A.  The  parameter  p  represents  the  remaining  pre¬ 
conditions  (initially  empty)  and  a  substitution  a 
(also  initially  empty)  will  be  built  up  by  the  algo¬ 
rithm.  It  first  deals  with  the  remaining  positive 
preconditions  and  uses  those  to  construct  the  sub¬ 
stitution  for  all  the  parameters  of  the  operators. 
Note  that  we  require  an  operator  to  mention  all 
its  parameters  in  the  positive  preconditions.  When 
the  positive  preconditions  have  been  tested,  the  al¬ 
gorithm  checks  the  negative  preconditions  under  a 
which  must  now  be  fully  ground.  Finally,  the  algo¬ 
rithm  tests  for  inconsistent  effects  by  doing  a  pair¬ 
wise  comparison  between  positive  and  negative  ef¬ 
fects.  This  algorithm  can  also  be  used  to  generate 
the  actions  for  the  next  action  layer  in  a  planning 
graph.  A  goal  regression  version  is  slightly  different 
as  it  is  no  longer  guaranteed  that  all  the  operator 
parameters  will  be  bound  after  the  unification  with 
a  goal  (and  possibly  static  preconditions). 

13  Reversible  Actions 

A  common  feature  in  many  planning  domains  (and 
in  many  classic  search  problems)  is  that  they  con¬ 
tain  actions  that  can  be  reversed  by  applying  an¬ 
other  action.  There  is  usually  no  need  to  consider 
such  actions  during  the  search  process. 

13.1  Reversible  Operators 

The  idea  here  is  to  apply  the  concept  of  reversibil¬ 
ity  to  operators:  an  operator  may  be  reversed  by 


another  operator  (or  the  same  operator),  possibly 
after  a  suitable  substitution  of  variables  occurring 
as  parameters  in  the  operator  definition.  Note  that 
this  definition  is  somewhat  narrow  as  it  demands 
this  pattern  to  be  consistent  across  all  instances  of 
the  two  operators,  i.e.  it  excludes  the  possibility  of 
an  operator  sometimes  being  reversed  by  one  oper¬ 
ator,  and  sometimes  by  another,  depending  on  the 
values  of  the  parameters. 

Definition  14  (reversing  operators)  An  ac¬ 
tion  a  that  is  applicable  in  a  state  s  is  reversed  by 
an  action  a'  if  the  state  that  results  from  applying 
the  sequence  ( aa ')  in  s  results  in  s,  i.e.  the  state 
remains  unchanged.  An  operator  O  is  reversed 
by  an  operator  O'  under  substitution  o’  iff  for 
every  action  a  =  er(O)  that  is  an  instance  of  O: 

•  if  a  is  applicable  in  a  state  s  then  a '  = 
cr(er'(0'))  is  applicable  in  y(s,a)  and 

•  7(l(s,a),a')  =  s. 

For  example,  consider  the  (move  ?r  ?11  ?12) 
operator  from  the  DWR  domain.  This  can  be  re¬ 
versed  by  another  move  operation  with  different 
parameters,  as  defined  by  the  substitution  a'  = 
{?11<-?12,?12^?11},  i.e.  (move  ?r  ?11  ?12)  is 
reversed  by  <T'((move  ?r  ?11  ?12))  =  (move  ?r 
?12  ?11). 

While  this  definition  captures  the  idea  of  a  re¬ 
versing  operator,  it  is  not  very  useful  from  a  com¬ 
putational  point  of  view.  Another  way  to  avoid 
exploring  states  that  are  the  result  of  the  applica¬ 
tion  of  an  action  followed  by  its  reverse  action  is 
to  store  all  states  in  a  hash  table  and  test  whether 
the  new  state  has  been  encountered  before,  an  ap¬ 
proach  that  is  far  more  general  than  just  testing  for 
reversing  actions.  Computationally,  it  is  roughly  as 
expensive  as  the  test  suggested  by  the  above  defi¬ 
nition.  The  key  here  is  that  both  are  state  specific. 
A  definition  of  reversibility  that  does  not  depend 
on  the  state  in  which  an  action  is  applied  would  be 
better. 

From  a  domain  author’s  perspective,  it  is  often 
possible  to  specify  which  operators  can  be  used  to 
reverse  another  operator,  as  we  have  shown  in  the 
DWR  move  example  above.  If  this  information 
is  available  during  search  then  there  is  no  need 
to  apply  the  reverse  action,  generate  the  state, 
and  compare  it  to  the  previous  state.  Instead 
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a  relatively  simple  substitution  test  would  suffice: 
a'  =  a  (a' (O')). 

Proposition  3  Let  0\  be  an  operator  with  positive 
effects  E f  and  negative  effects  E ”  that  is  reversed 
by  O2  with  positive  effects  E%  and  negative  effects 
Etf  under  substitution  o’ .  Then  the  two  sets  of  pos¬ 
itive/negative  effects  must  cancel  each  other: 

E{  =  a'(E%)  and  E J>  =  a'(E%) 

Suppose  there  is  a  positive  effect  in  E\  that  is  not 
in  a' {Elf).  Now  suppose  an  instance  of  O  was  ap¬ 
plied  in  a  state  in  which  the  effect  in  question  does 
not  already  hold.  The  effect  would  then  be  added 
by  the  instance  of  O  but  it  would  not  be  deleted 
by  the  reversing  action,  and  thus  the  original  state 
and  the  state  resulting  from  the  two  actions  in  se¬ 
quence  would  not  be  the  same.  A  similar  argument 
holds  for  an  effect  in  E ”  that  is  not  in  crfE^).  ■ 

This  means  we  can  let  the  domain  author  spec¬ 
ify  reversing  operators  and  then  use  the  above  nec¬ 
essary  criterion  for  validation.  Or  we  could  treat 
the  above  criterion  as  sufficient  and  thus  exclude 
a  portion  of  the  search  space.  This  may  lead  to 
an  incompleteness  in  the  search,  but  the  domains 
we  have  used  for  our  evaluation  do  not  show  this 
problem. 

13.2  Unique  Reversibility 

In  fact  we  have  made  an  even  stronger  assumption 
to  carry  out  some  experiments  with  the  domains 
mentioned  above:  we  have  assumed  that  there  is  at 
most  one  operator  that  reverses  a  given  operator. 
We  have  then,  for  each  domain,  done  a  pairwise 
test  on  all  the  operators  defined  in  the  domain  to 
see  whether  the  necessary  criterion  holds.  This  re¬ 
sulted  in  discovering  that  the  move  operator  can  be 
reversed  by  itself  with  a  substitution  automatically 
derived  from  the  operator  definition,  and  similarly 
it  discovered  the  reversibility  between  the  take  and 
put  operators  and  the  load  and  unload  operators  in 
the  DWR  domain. 

Perhaps  surprisingly,  the  unique  reversibility  was 
not  given  for  all  domains.  The  logistics  domain 
contains  load  and  unload  operators  for  trucks  and 
airplanes.  These  are  specified  as  four  distinct  op¬ 
erators.  However,  in  terms  of  their  effects  the  two 
load  operators  and  the  two  unload  operators  can¬ 
not  be  distinguished.  The  only  difference  lies  in 


the  preconditions  where  the  ?truck  parameter  is 
required  to  be  a  truck  and  the  ?airplane  parame¬ 
ter  is  required  to  be  an  airplane. 

This  result  can  be  interpreted  in  two  ways:  one 
could  argue  that  the  necessary  condition  may  not 
be  used  as  sufficient  in  this  domain.  Or  one  could 
argue  that  this  domain  contains  redundancy  that 
can  be  removed  by  merging  the  two  load  and  unload 
operators,  which  would  not  change  the  set  of  reach¬ 
able  states  in  this  example  but  means  the  planner 
has  fewer  actions  to  consider.  Either  way,  testing 
for  the  necessary  reversibility  condition  has  high¬ 
lighted  this  domain  feature. 

14  Communicating  Plans: 
Methods,  Assumptions, 
and  Procedures 

Most  of  the  research  in  AI  planning  has  focussed  on 
algorithms  for  the  efficient  discovery  of  plans  that 
solve  a  given  planning  problem.  In  this  work  we 
are  not  interested  in  this  classical  problem,  but  in 
the  question  how  an  agent  framework  can  support 
the  distributed  execution  of  plans.  This  is  closely 
intertwined  with  the  classic  planning  problem,  of 
course,  when  execution  fails  and  the  plan  needs  to 
be  modified. 

The  remainder  of  this  report  is  structured  as 
follows.  In  the  next  section  we  shall  give  a  brief 
overview  of  the  two  approaches  that  have  been  un¬ 
dertaken  to  provide  the  foundation  for  meaningful 
agent  communication.  Such  communication  is  re¬ 
quired  to  manage  the  successful  sharing  and  execu¬ 
tion  of  plans  amongst  a  group  of  distributed  agents. 
This  will  define  the  message  structure,  communica¬ 
tive  acts,  and  interaction  protocols  for  agent  collab¬ 
oration.  We  will  then  extend  the  protocols  specif¬ 
ically  to  support  distributed  plan  execution.  This 
will  be  followed  by  a  discussion  on  plan  failure  and 
how  this  can  be  handled. 

15  Background:  Agent  Com¬ 
munication 

Meaningful  agent  communication  is  a  difficult  prob¬ 
lem  that  has  been  addressed  in  agent  research  by 
two  major  efforts:  the  Knowledge  Sharing  Effort 
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(KSE)  and  the  Foundation  for  Intelligent  Physical 
Agents  (FIPA).  Both  approaches  rely  on  the  exis¬ 
tence  of  a  transport  layer  that  allows  the  exchange 
of  messages  between  agents.  At  this  layer  a  mes¬ 
sage  is  a  stream  of  bytes  that  have  no  pre-defined 
meaning.  This  is  sufficient  for  many  applications 
in  which  the  software  developer  knows  the  mean¬ 
ing  of  these  bytes  and  the  correct  behavior  can  be 
hard-coded  into  the  software.  Such  software  would 
normally  not  be  considered  an  agent.  For  software 
to  be  considered  an  agent  it  should  be  capable  of 
communicating  in  a  semantically  rich,  that  is,  a 
meaningful  language,  and  for  an  agent  to  be  capa¬ 
ble  of  meaningful  communication,  the  meaning  has 
to  exist  not  only  in  the  software  developer’s  head, 
but  it  has  to  be  somehow  encoded  in  the  system  of 
communicating  agents. 

The  first  step  towards  encoding  meaning  in  an 
agent  communication  language  usually  consists  of 
the  definition  of  an  ontology  that  defines  the  terms 
that  can  be  used  for  communication.  The  sym¬ 
bols  used  to  represent  these  terms  have  meaning 
because  they  are  related  to  other  terms  through  a 
set  of  pre-defined  relations  that  constrain  the  pos¬ 
sible  interpretations.  Thus,  an  ontology  that  con¬ 
tains  only  one  symbol  has  no  meaning  as  it  is  en¬ 
tirely  unconstrained.  On  the  other  hand  an  on¬ 
tology  that  contains  many  symbols  and  relations 
between  them  does  encode  meaning  for  these  sym¬ 
bols.  For  agent  communication,  if  two  agents  refer 
to  the  same  ontology,  it  can  be  assumed  that  they 
are  using  the  symbols  in  their  messages  with  the 
same  meaning.  An  ontology  can  be  seen  as  provid¬ 
ing  the  vocabulary  for  meaningful  communication 
and  the  conceptual  framework  described  in  the  first 
report  constitutes  part  of  such  an  ontology,  namely 
one  focussed  on  plans. 

A  shared  ontology  is  necessary,  but  not  suffi¬ 
cient  for  meaningful  agent  communication.  To  form 
meaningful  statements  it  is  necessary  to  define  a  set 
of  grammatical  rules  that  define  how  the  symbols 
from  an  ontology  can  be  combined  to  form  more 
complex  structures.  Furthermore,  a  formal  seman¬ 
tics  is  needed  to  define  what  exactly  it  means  to 
put  certain  symbols  together  in  a  certain  way.  To¬ 
gether,  syntax  and  semantics  define  a  formal  lan¬ 
guage  that  can  be  used  for  meaningful  agent  com¬ 
munication.  While  an  ontology  is  always  finite, 
such  a  language  usually  allows  for  an  infinite  num¬ 
ber  of  statements  to  be  formed,  making  it  possible 


to  express  an  infinite  number  of  facts,  or  plans. 

An  ontology  and  a  formal  language  are  still 
not  sufficient  for  meaningful  agent  communication 
though.  Meaningful  agent  communication  also  re¬ 
quires  agent  messages  to  encode  modalities.  For  ex¬ 
ample,  an  agent  might  have  a  fact  in  its  knowledge 
base  and  it  can  send  this  as  a  message  to  another 
agent,  but  what  is  the  receiving  agent  meant  to  do 
with  this  message.  Is  the  sender  telling  it  about  a 
fact  it  believes,  or  is  it  asking  whether  the  receiv¬ 
ing  agent  believes  the  content  of  the  message.  If  the 
content  is  a  plan,  is  the  sender  asking  the  receiver 
to  execute  the  plan,  or  should  it  evaluate  the  plan 
and  give  feedback,  or  is  it  to  refine  the  plan  plan 
with  local  knowledge  into  a  more  detailed  plan? 
The  modalities  required  to  answer  these  questions 
are  usually  defined  as  performatives  that  describe 
communicative  acts  and  form  part  of  an  agent  com¬ 
munication  message.  Statements  describing  factual 
knowledge  or  plans  (built  using  the  ontology  and 
formal  language)  are  usually  used  at  the  content 
level,  i.e.  they  provide  the  object  of  a  message  us¬ 
ing  a  given  performative. 

We  will  now  look  at  the  performatives  defined  in 
the  two  efforts  mentioned  above,  KSE  and  FIPA. 
More  specifically,  we  will  look  at  the  performatives 
they  define  that  can  be  used  to  support  plan  exe¬ 
cution  and  agent  communication  about  plans. 

15.1  Knowledge  Sharing  and  KQML 

In  the  Knowledge  Sharing  Effort,  the  language 
for  expressing  ontologies  is  called  Ontolingua,  and 
the  formal  language  for  representing  content  is  the 
Knowledge  Interchange  Format  (KIF).  The  lan¬ 
guage  for  expressing  complete  agent  communica¬ 
tion  messages  based  on  different  performatives  and 
containing  content  in  KIF  (or  some  other  content 
language)  is  the  Knowledge  Query  and  Manipula¬ 
tion  Language  (KQML)  [Labrou  and  Finin,  1997]. 
Before  we  look  at  the  performatives  defined  in 
KQML,  we  shall  have  a  brief  look  at  the  structure 
of  a  KQML  message.  This  will  clarify  the  relation 
between  a  KQML  message  and  its  content,  which 
is  not  limited  to  KIF,  but  could  also  be  expressed 
in  a  different  language  such  as  a  CPR/BDI-based 
plan  representation. 

In  the  KSE  framework,  agents  can  send  messages 
to  each  other  and  KQML  is  a  standard  that  defines 
the  syntax  of  a  single  message.  As  the  language  is 
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based  on  a  LISP-like  syntax,  a  message  is  a  list  of 
symbols  surrounded  by  brackets: 

<message>  ::=  (  <perf ormative> 

{  <keyword>  <value>}*  ) 

The  first  element  in  this  list  is  the  performative 
that  defines  what  type  of  communicative  act  this 
message  represents.  The  performative  describes 
what  the  sender  wants  the  receiver  to  do  with  the 
content.  If  the  content  is  factual,  for  example,  the 
sender  may  use  the  tell  performative  to  indicate 
that  the  receiver  should  (from  now  on)  believe  the 
given  fact.  If  the  performative  was  ask,  the  sender 
will  expect  a  reply  indicating  whether  the  receiver 
believes  the  given  fact.  If  the  content  is  a  plan  a 
different  set  of  performatives  may  be  used,  e.g.  to 
tell  the  receiver  to  execute,  evaluate,  or  refine  the 
given  plan. 

The  remainder  of  a  KQML  message  are  alternat¬ 
ing  keywords  and  values.  KQML  defines  a  number 
of  keywords  that  can  be  used  in  a  message: 

•  :  sender:  the  sender  of  this  message; 

•  :  receiver:  the  receiver  of  this  message; 

•  :  from:  the  original  sender  of  a  forwarded  mes¬ 
sage; 

•  :to:  the  final  receiver  of  a  forwarded  message; 

•  :  in-reply-to:  a  label  that  allows  to  tie  this 
message  to  a  previous  message; 

•  :  reply-with:  a  label  that  allows  to  tie  this 
message  to  a  future  message; 

•  :  language:  the  name  of  the  representation 
language  used  in  the  content; 

•  :  ontology:  the  name  of  the  ontology  used  in 
the  content; 

•  :  content:  the  content  with  respect  to  which 
this  performative  is  applied. 

The  first  four  keywords  are  used  to  identify  the 
agents  participating  in  the  communication.  The 
next  two  can  be  used  to  put  this  message  into  a 
larger  context:  a  conversation  consisting  of  multi¬ 
ple  messages. 

For  the  present  discussion  the  last  three  keywords 
are  the  most  relevant.  What  KQML  provides  here 


is  a  mechanism  that  allows  for  the  plugging  in  of  a 
different  language  for  the  content,  that  is,  for  the 
direct  object  of  the  communicative  act.  For  exam¬ 
ple,  if  the  message  is  about  a  plan,  this  plan  can 
be  sent  as  the  content  of  a  message.  The  ontol¬ 
ogy  explicitly  references  the  set  of  terms  that  will 
be  used  in  the  content,  which  defines  a  meaning¬ 
ful  vocabulary.  In  a  planning  context  this  could  be 
the  CPR/BDI  ontology.  The  language  explicitly 
specifies  the  formal  language  used  to  represent  the 
content.  This  could  be  an  XML-based  language 
or  a  LISP-like  syntax2,  for  example.  If  the  mes¬ 
sage  was  about  factual  information,  the  content 
language  would  presumably  have  to  be  a  different 
language,  e.g.  KIF. 

To  summarize,  a  KQML  message  consists  of  a 
performative  defining  the  modality  of  the  message 
and  a  set  of  keyword- value  pairs  defining  to  agents 
involved,  references  to  the  context,  and  the  content 
of  the  message  which  can  be  given  in  an  explic¬ 
itly  specified  representation  language  that  is  not 
defined  as  part  of  KQML. 

15.1.1  Performatives 

Given  our  focus  on  distributed  planning  and  execu¬ 
tion,  we  are  most  concerned  with  agent  communi¬ 
cation  where  the  content  of  a  message  is  a  plan,  or 
at  least  activity-related.  We  shall  now  have  a  look 
at  the  performatives  defined  in  KQML  to  see  which 
communicative  acts  related  to  distributed  planning 
and  execution  are  available  in  this  language.  The 
complete  list  of  performatives  defined  in  KQML  is 
given  in  Appendix  A.  These  performatives  can  be 
divided  into  three  groups,  depending  on  the  type 
of  objects  (the  content)  the  communicative  acts  are 
about: 

•  Messages  about  facts:  Performatives  from 
this  group  allow  agents  to  interact  with  each 
other’s  knowledge,  either  telling  them  about 
facts  that  they  believe  to  hold,  or  asking  them 
about  facts.  If  the  answer  consists  of  many 
parts,  it  can  be  streamed  rather  than  sent  in 
one  large  message. 

“While  the  syntax  of  the  content  language  is  not  con¬ 
strained  in  KQML,  the  problem  of  parsing  a  complete  mes¬ 
sage  means  that  it  must  be  possible  to  at  least  recognize  the 
end  of  the  content  somehow. 


37 


Distribution  A:  Approved  for  public  release;  distribution  is  unlimited. 


•  Messages  about  activities:  Performatives  from 
this  group  allow  agents  to  ask  each  other  to 
achieve  given  goals.  The  achievement  clearly 
involves  the  execution  of  activity,  although  this 
is  not  explicitly  mentioned  in  the  message. 
Furthermore,  since  the  content  of  the  message 
is  a  goal,  the  representation  of  plans  is  not  re¬ 
quired. 

•  Messages  about  capabilities:  Performatives 
from  this  group  allow  agents  firstly  to  register 
capabilities  with  a  central  capability  broker, 
and  secondly  to  find  agents  that  have  required 
capabilities.  The  broker  may  then  manage  the 
application  of  a  capability. 


The  first  set  of  performatives  is  not  activity- 
related  at  all  and  can  be  ignored  for  the  present 
discussion. 

The  second  set  indirectly  deals  with  activities. 
With  the  achieve  performative  the  sender  asks  the 
receiver  “to  want  to  try  to  make  the  content  true 
of  the  system”.  We  shall  interpret  this  as  the  set¬ 
ting  of  a  goal  in  the  classical  planning  sense,  i.e. 
the  receiver  should  come  up  with  and  execute  a 
plan  that  will  achieve  said  goal  in  the  world  state. 
Presumably  this  will  require  the  receiver  to  per¬ 
form  some  actions.  However,  the  actions  them¬ 
selves  are  not  subject  to  agent  communication  in 
KQML.  The  other  performative  that  relates  to  ac¬ 
tivity  is  unachieve,  which  should  only  be  used  after 
an  achieve  relating  to  the  same  goal.  From  a  plan¬ 
ning  perspective  this  could  be  the  same  as  another 
achieve  message  with  a  negative  goal,  achieve 
and  unachieve  are  the  only  performatives  dealing 
with  goals. 

The  third  set  can  be  used  for  capability  broker¬ 
ing.  The  central  performative  here  is  advertise 
with  which  an  agent  can  announce  that  it  is  capa¬ 
ble  of  processing  a  given  type  of  message.  While 
capabilities  in  general  deal  with  activities,  a  capa¬ 
bility  advertisement  in  KQML  only  describes  the 
message  type  that  can  be  processed,  i.e.  the  con¬ 
tent  will  itself  be  another  KQML  message  and  not 
an  activity  or  a  plan.  Thus,  the  performatives  from 
this  set  cannot  be  considered  to  be  activity-related 
in  KQML. 


15.1.2  Protocols 

Messages  between  agents  are  intended  to  appear  as 
part  of  a  dialogue  or  a  larger  communication  struc¬ 
ture.  A  protocol  is  such  a  structure  and  it  can  be 
described  as  a  communication  plan  schema,  i.e.  all 
the  actions  in  the  plan  schema  are  communication 
actions  using  the  KQML  performatives.  Protocols 
are  schemata  in  the  sense  that  an  actual  communi¬ 
cation  represents  an  instantiation  of  the  schema. 

While  the  KQML  specification  describes  the  con¬ 
text  in  which  certain  message  types  may  occur, 
there  is  no  formal  specification  that  describes  the 
interactions  that  may  take  place. 

15.2  The  FIPA  Agent  Communica¬ 
tion  Language 

The  Foundation  for  Intelligent  Physical  Agents 
(FIPA)  has  proposed  an  alternative  standard  for 
an  Agent  Communication  Language  (ACL).  As  for 
KQML,  we  shall  first  look  at  the  message  structure 
defined  in  FIPA  ACL  and  then  the  set  of  performa¬ 
tives  defined  in  this  standard,  focussing  on  those 
that  deal  with  activity  management. 

15.2.1  Message  Structure 

The  structure  of  a  FIPA  ACL  message3  is  very 
similar  to  that  proposed  in  KQML.  Each  message 
must  have  a  performative  that  describes  the  type  of 
communicative  act  the  message  represents.  The  re¬ 
mainder  of  the  message  contains  fields  for  describ¬ 
ing  the  participants  in  the  communication,  tying 
the  message  into  a  conversation  consisting  of  mul¬ 
tiple  messages,  and  the  actual  content  of  the  mes¬ 
sage.  In  detail,  a  FIPA  ACL  message  contains: 

•  performative:  denotes  the  type  of  the  com¬ 
municative  act  of  the  ACL  message; 

•  sender:  denotes  the  identity  of  the  sender  of 
the  message,  that  is,  the  name  of  the  agent  of 
the  communicative  act; 

•  receiver:  denotes  the  identity  of  the  intended 
recipients  of  the  message; 

3See  http:/ /www. fipa.org/repository/standardspecs.html 
for  the  set  of  documents  describing  the  FIPA  standard. 
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•  reply-to:  indicates  that  subsequent  messages 
in  this  conversation  thread  are  to  be  directed 
to  the  agent  named  in  the  reply-to  parameter, 
instead  of  to  the  agent  named  in  the  sender 
parameter; 

•  content:  denotes  the  content  of  the  message; 
equivalently  denotes  the  object  of  the  action: 
the  meaning  of  the  content  of  any  ACL  mes¬ 
sage  is  intended  to  be  interpreted  by  the  re¬ 
ceiver  of  the  message; 

•  language:  denotes  the  language  in  which  the 
content  parameter  is  expressed; 

•  encoding:  denotes  the  specific  encoding  of  the 
content  language  expression; 

•  ontology:  denotes  the  ontology(s)  used  to 
give  a  meaning  to  the  symbols  in  the  content 
expression; 

•  protocol:  denotes  the  interaction  protocol 
that  the  sending  agent  is  employing  with  this 
ACL  message; 

•  conversation-id:  introduces  an  expression 
(a  conversation  identifier)  which  is  used  to 
identify  the  ongoing  sequence  of  communica¬ 
tive  acts  that  together  form  a  conversation; 

•  reply-with:  introduces  an  expression  that 
will  be  used  by  the  responding  agent  to  iden¬ 
tify  this  message; 

•  in-reply-to:  denotes  an  expression  that  ref¬ 
erences  an  earlier  action  to  which  this  message 
is  a  reply; 

•  reply-by:  denotes  a  time  and/or  date  expres¬ 
sion  which  indicates  the  latest  time  by  which 
the  sending  agent  would  like  to  receive  a  reply. 

Like  KQML,  the  fields  for  describing  the  partici¬ 
pants  include  the  sender  and  receiver.  The  fields  to 
do  with  message  forwarding  are  not  supported  in 
FIPA.  Instead,  the  reply-to  field  can  be  used  to 
specify  a  different  response  address.  Conceptually, 
these  differences  are  hardly  significant. 

Similarly,  the  fields  for  conversation  management 
are  not  fundamentally  different:  two  additional 
fields  are  defined  in  FIPA,  conversation-id  and 
reply-by,  where  the  latter  allows  the  specification 


of  a  deadline  at  the  envelope  level,  something  that 
has  to  be  done  as  part  of  the  message  content  in 
KQML. 

Finally,  the  language  used  for  the  content  is  not 
defined  in  the  standard  and  various  fields  in  a  mes¬ 
sage  specify  what  formal  structure  is  used.  Again, 
the  ontology  and  the  formal  language  can  be  named 
explicitly.  In  addition,  FIPA  ACL  allows  the  ex¬ 
plicit  naming  of  the  protocol  that  underlies  the  con¬ 
version  to  which  a  message  belongs. 

15.2.2  Performatives 

The  complete  list  of  performatives  defined  in  FIPA 
ACL  is  given  in  Appendix  B.  These  can  be  roughly 
divided  into  three  sets  based  on  the  type  of  content 
and  the  protocols  these  performatives  are  expected 
to  be  used  in: 

•  Messages  about  facts:  Performatives  from  this 
group  are  concerned  with  knowledge  manipu¬ 
lation  where  each  agent  has  its  own  knowledge¬ 
base  and  agent  communication  is  used  to 
update  and  query  information  across  agent 
knowledge-bases . 

•  Message  about  collaboration:  Performatives 
from  this  group  can  be  used  to  organize  a  col¬ 
laboration  between  agents.  Essentially,  these 
performatives  implement  the  Contract  Net 
protocol  [Smith,  1980]. 

•  Messages  about  communication  management: 
Performatives  from  this  group  allow  message 
forwarding  and  a  single  performative  that  can 
be  used  to  indicate  that  a  received  message  was 
not  understood. 

As  for  KQML,  the  first  set  deals  with  factual 
knowledge  and  not  with  activity.  The  content  of 
messages  using  these  performatives  could  again  be 
expressed  in  KIF  or  some  other  logical  language. 

The  second  set  corresponds  to  the  brokering- 
related  performatives  in  KQML.  However,  whereas 
KQML  used  itself  as  a  content  language  (defining 
the  type  of  message  that  can  be  processed),  FIPA 
ACL  is  based  on  the  Contract  Net  protocol  in  which 
the  central  element  is  a  proposal  for  work.  Thus, 
the  content  of  most  messages  must  be  about  such  a 
proposal.  Unfortunately  neither  the  document  that 
specifies  the  performatives  nor  the  document  that 
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defines  the  contract  net  interaction  protocol  defines 
what  a  proposal  should  look  like  or  what  type  of 
representation  might  be  used  here4.  Two  options, 
at  least  from  an  AI  planning  perspective,  would  be 
to  use  a  goal-based  or  a  task-based  representation, 
but  this  is  only  speculation.  Another  issue  with 
the  performatives  provided  by  FIPA  is  that  they 
focus  on  the  phase  leading  up  to  a  collaboration, 
but  provide  little  for  managing  the  distributed  ac¬ 
tivities  that  implement  the  collaboration.  No  per¬ 
formatives  related  to  plan  sharing  and  execution 
are  defined  in  FIPA  ACL. 

The  third  set  of  performatives  are  not  related  to 
activities  and  thus  not  of  interest  to  us. 

15.2.3  Protocols 

An  area  in  which  the  FIPA  standard  is  clearly  more 
advanced  than  the  KSE  specifications  is  the  set  of 
interaction  protocols  that  define  how  single  mes¬ 
sages  can  be  used  in  conversations.  FIPA  defines 
the  following  interaction  protocols  in  detail: 

•  FIPA  Request  Interaction  Protocol  Specifica¬ 
tion:  allows  one  agent  to  request  another  to 
perform  some  action. 

•  FIPA  Query  Interaction  Protocol  Specifica¬ 
tion:  allows  one  agent  to  request  to  perform 
some  kind  of  action  on  another  agent. 

•  FIPA  Request  When  Interaction  Protocol 
Specification:  allows  an  agent  to  request  that 
the  receiver  perform  some  action  at  the  time  a 
given  precondition  becomes  true. 

•  FIPA  Contract  Net  Interaction  Protocol  Spec¬ 
ification:  a  minor  modification  of  the  original 
contract  net  IP  pattern  in  that  it  adds  rejec¬ 
tion  and  confirmation  communicative  acts. 

•  FIPA  Iterated  Contract  Net  Interaction  Pro¬ 
tocol  Specification:  an  extension  of  the  basic 
FIPA  Contract  Net  IP,  but  it  differs  by  allow¬ 
ing  multi-round  iterative  bidding. 

•  FIPA  Brokering  Interaction  Protocol  Specifi¬ 
cation:  designed  to  support  capability  broker¬ 
age  interactions  in  mediated  systems  and  in 
multi-agent  systems. 

4FIPA  also  includes  a  specification  for  a  content  lan¬ 
guage,  the  FIPA  SL  content  language,  but  it  is  not  obvious 
how  a  protocol  might  be  expressed  in  this  language. 


•  FIPA  Recruiting  Interaction  Protocol  Specifi¬ 
cation:  designed  to  support  recruiting  interac¬ 
tions  in  mediated  systems  and  in  multi-agent 
systems. 

•  FIPA  Subscribe  Interaction  Protocol  Specifi¬ 
cation:  allows  an  agent  to  request  a  receiv¬ 
ing  agent  to  perform  an  action  on  subscription 
and  subsequently  when  the  referenced  object 
changes. 

•  FIPA  Propose  Interaction  Protocol  Specifica¬ 
tion:  allows  an  agent  to  propose  to  receiving 
agents  that  the  initiator  will  do  the  actions 
described  in  the  propose  communicative  act 
when  the  receiving  agent  accepts  the  proposal. 

A  number  of  these  protocols  deal  with  capabil¬ 
ity  brokering  and  are  thus  relevant  to  distributed 
planning  and  plan  execution.  However,  only  one 
of  the  protocols  deals  directly  with  the  distributed 
execution  of  activity,  namely  the  FIPA  Request  in¬ 
teraction  protocol.  An  overview  of  the  messages  to 
be  exchanged  as  part  of  this  protocol  is  given  in 
figure  12. 

The  interaction  protocol  involves  two  agents,  the 
initiator  that  wants  another  agent  to  execute  some 
action,  and  the  so-called  participant  that  executes 
the  action.  The  first  step  in  the  interaction  proto¬ 
col  consists  of  the  initiator  sending  a  request  mes¬ 
sage  to  the  participant,  that  is,  a  message  with  the 
request  performative  and  an  action  as  the  content 
of  the  message.  What  language  the  action  is  to  be 
described  in  is  not  specified  in  the  protocol  and  the 
idea  is,  of  course,  that  the  outer  layer  can  encapsu¬ 
late  different  content  languages. 

The  participant  has  to  respond  to  this  message 
with  either  a  refuse  or  an  accept  message.  In  the 
former  case  the  protocol  is  terminated  and  no  fur¬ 
ther  messages  will  be  exchanged.  In  the  latter  case 
the  interaction  continues.  Presumably,  the  partic¬ 
ipant  will  execute  the  requested  action  and  then 
send  a  message  indicating  the  status  of  the  action 
to  the  initiator.  Depending  on  the  outcome  of  the 
action,  the  message  can  be  a  failure  message  or 
an  inform  message.  This  message  terminates  the 
interaction. 

This  basic  protocol  only  shows  the  flow  of  mes¬ 
sages  when  things  go  according  to  plan,  so  to  speak. 
Either  participant  may  also  terminate  the  proto¬ 
col  when  they  receive  a  message  they  cannot  pro- 
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— » command  a 


Figure  12:  FIPA  Request  Interaction  Protocol 


reject  - 


Figure  13:  Protocol  for  Activity  Execution 


cess,  by  sending  a  not-understood  message.  Fur¬ 
thermore,  the  initiator  can  send  a  cancel  message, 
asking  the  participant  to  abandon  execution  of  the 
action.  How  this  is  possible  depends  on  the  action, 
of  course. 


16  Agent  Communication  for 
Plan  Execution 

In  this  section  we  will  extend  the  basic  request  in¬ 
teraction  protocol  defined  in  FIPA  to  define  more 
complex  protocols  that  allow  for  more  detailed  con¬ 
trol  of  the  execution,  and  which  build  on  some  of 
the  features  of  the  CPR/BDI  representation  that 
may  be  used  at  the  content  level. 

16.1  Simple  Action  Execution 

The  first  protocol  we  have  developed  is  a  slightly 
more  complex  version  of  the  FIPA  request  interac¬ 
tion  protocol  that  differs  from  the  FIPA  protocol 
in  two  ways:  firstly,  it  allows  the  executing  agent 
to  renege  after  it  has  accepted,  and  secondly,  the 
protocol  is  more  detailed  with  respect  to  the  in¬ 
formation  that  indicates  the  status  of  execution  to 
the  requester.  A  concise  overview  of  the  protocol 
is  shown  in  figure  13. 

This  protocol  is  shown  here  from  the  perspec¬ 
tive  of  the  action-executing  agent.  A  correspond¬ 
ing  version  for  the  requester  would  look  very  sim¬ 
ilar.  Nodes  in  this  graph  represent  internal  states 
of  the  agent  with  respect  to  the  protocol.  Arcs  rep- 
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resent  possible  state  transitions  that  can  occur  due 
to  a  message  being  sent  or  received.  The  message 
is  given  as  a  label  on  the  arc.  A  message  being  re¬ 
ceived  is  indicated  by  an  arrow  before  the  message 
and  a  message  being  sent  is  indicated  by  an  arrow 
after  the  message.  States  in  which  the  protocol  can 
be  terminated  are  shown  gray. 

The  protocol  is  initiated  with  an  incoming  mes¬ 
sage  in  which  a  command  is  issued.  This  essentially 
corresponds  to  the  request  message  in  FIPA.  The 
terminology  is  different  to  indicate  that  this  mes¬ 
sage  represents  the  issuing  of  a  command  rather 
than  a  request.  This  indicates  that  the  sender  must 
have  authority  to  issue  commands  to  the  receiver, 
which  may  be  due  to  a  pre-existing  authority  rela¬ 
tionship  or  some  prior  negotiation  that  has  taken 
place  (by  means  of  another  protocol  not  defined 
here) . 

Given  that  the  sending  agent  has  authority  over 
the  receiving  agent,  the  expected  response  would  be 
for  the  receiver  to  accept.  However,  there  may  be  a 
reason  why  the  receiver  has  to  reject,  for  example, 
if  a  resource  required  for  the  action  execution  is 
currently  unavailable.  Thus,  the  executing  agent 
has  to  respond  to  accept  or  reject  the  command. 

It  is  not  assumed  that  commands  are  only  issued 
for  immediate  action.  Normally,  there  would  be  a 
time  interval  specified  as  part  of  the  activity  de¬ 
scription:  CPR/BDI  allows  for  at  least  two  time 
points  to  be  specified  with  any  activity,  beginning 
and  end  of  the  activity.  This  means  that  things  can 
happen  after  the  acceptance  of  a  command  and  the 
start  of  the  corresponding  action.  If  something  hap¬ 
pens  that  means  the  receiver  can  no  longer  execute 
the  command,  it  has  to  send  a  renege  message  to 
the  agent  that  issued  the  command. 

When  the  executing  agent  begins  with  the  exe¬ 
cution,  it  has  to  send  an  according  message  to  the 
agent  that  issued  the  command.  At  this  point  the 
executing  agent  is  said  to  be  “performing” ,  a  block 
that  will  be  reused  in  later  protocols  and  thus  in¬ 
dicated  as  a  box  in  figure  13. 

In  CPR/BDI,  as  in  most  AI  planning  represen¬ 
tations,  an  action  is  associated  with  effects,  that  is, 
fluent  relations  in  the  world  state  that  change  as 
a  direct  result  of  the  action  being  executed.  Given 
that  we  consider  actions  to  be  temporal,  effects  can 
occur  at  different  time  points,  but  not  before  an 
action  has  been  started.  Some  effects  will  occur 
immediately  after  the  beginning  of  an  action  (es- 


Figure  14:  Abandoning  Execution 

pecially  negative  effects,  e.g.  when  a  robot  moves 
away  from  a  location)  and  others  may  occur  later. 
Some  actions  even  have  effects  after  the  end  of  the 
execution  (e.g.  the  paint  being  dry  after  the  exe¬ 
cution  of  a  paint  action) . 

In  the  protocol  described  here  the  executing 
agent  is  expected  to  send  progress  reports  to  the 
commanding  agent  every  time  and  effect  is  achieved 
and  when  the  action  has  been  completed.  Assum¬ 
ing  a  shared  model  of  the  action  the  command¬ 
ing  agent  can  then  monitor  the  progress  and  knows 
when  the  effects  can  be  used  by  other  agents  and 
actions,  or  when  execution  deviates  from  the  model, 
which  could  be  considered  a  failure.  Note  that  this 
is  a  far  more  detailed  model  of  a  failure  than  the 
simple  message  in  the  FIPA  protocol. 

16.2  Abandoning  Execution 

In  an  extension  to  the  basic  protocol  the  FIPA 
specification  allows  the  commanding  agent  to  send 
a  cancel  message.  The  executing  agent  is  meant 
to  somehow  stop  executing  the  command  at  this 
point.  Figure  14  shows  an  extended  version  of  the 
protocol  described  above  to  allow  for  similar  func¬ 
tionality:  abandoning  the  action  at  any  stage. 

The  protocol  is  initiated  as  before  by  the  com¬ 
mander  sending  a  command  to  the  executing  agent. 
Assuming  that  the  executing  agent  does  not  re¬ 
spond  immediately  (presumably  it  will  have  to  do 
some  planning  before  it  can  accept),  it  is  possible 
that  the  commander  cancels  the  command  before 
the  executing  agent  accepts  or  rejects.  This  would 
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terminate  the  protocol  and  should  not  lead  to  fur¬ 
ther  complications. 

If  the  executing  agent  rejects  the  protocol  is  ter¬ 
minated,  as  before.  If  it  accepts,  the  commander 
may  still  cancel  the  command  before  the  execution 
begins.  Again,  this  should  not  lead  to  further  com¬ 
plications  and  simply  terminate  the  protocol. 

However,  things  become  more  complex  once  the 
execution  has  started,  and  the  commander  will  be 
aware  of  this  because  it  has  received  an  according 
message  from  the  executing  agent.  If  the  comman¬ 
der  does  not  issue  a  message  asking  for  the  aban¬ 
donment  of  execution,  the  protocol  proceeds  as  be¬ 
fore:  the  executing  agent  sends  messages  when  ef¬ 
fects  have  been  achieved  and  when  the  action  has 
been  completed.  Once  the  action  has  been  com¬ 
pleted  it  can  no  longer  be  abandoned,  even  if  there 
are  delayed  effects  still  taking  place. 

How  an  action  can  be  abandoned  during  execu¬ 
tion  clearly  depends  on  the  action  in  question.  We 
shall  assume  here  that  there  are  various  points  dur¬ 
ing  an  execution  at  which  an  action  can  be  aban¬ 
doned.  Clearly,  effects  that  have  already  occurred 
at  the  point  of  abandonment  are  not  automatically 
undone.  However,  future  effects  may  or  may  not 
be  achieved.  In  fact,  there  may  be  a  different  set 
of  effects  that  has  to  be  expected  depending  on  the 
point  at  which  an  action  is  abandoned.  The  proto¬ 
col  we  have  defined  is  based  on  this  model:  normal 
performing  is  abandoned,  but  the  performance  of 
some  other  action  now  continues.  This  will  result 
in  effects  being  achieved  and  these  will  be  relayed 
through  messages  to  the  commander,  including  the 
completion  of  the  changed  activity. 

Ideally,  the  commander  and  the  executing  agent 
have  a  shared  model  of  activity  that  specifies  how 
actions  can  be  abandoned.  This  could  be  done 
through  one  set  of  effects  for  normal  execution,  and 
various  sets  of  additional  effects  associated  with 
different  time  points  at  which  the  action  may  be 
abandoned.  If  the  action  cannot  be  abandoned, 
the  model  collapses  into  the  classical  model:  an  ac¬ 
tion  with  a  set  of  preconditions  and  effects.  Given 
such  a  shared  model  it  would  be  possible  for  the 
commander  to  anticipate  the  result  of  abandoning 
an  action  and  hence,  making  a  more  informed  de¬ 
cision. 


Figure  15:  Protocol  for  Plan  Execution 

16.3  Execution  of  Plans 

The  next  step  to  extending  the  protocol  involves 
the  commanding  agent  sending  a  whole  plan  to  the 
executing  agent.  For  simplicity,  this  plan  is  as¬ 
sumed  to  be  a  sequence  of  actions.  Each  action 
in  the  plan  must  have  a  unique  label  so  that  it  can 
be  uniquely  identified  in  the  plan.  The  protocol 
outline  is  shown  in  figure  15,  again  from  the  per¬ 
spective  of  the  executing  agent. 

As  before,  the  protocol  begins  with  the  comman¬ 
der  issuing  the  command,  which  is  a  plan.  The  ex¬ 
ecuting  agent  can  either  reject  or  accept  this  plan, 
where  acceptance  is  the  expected  behavior.  Also, 
the  executing  agent  can  renege  before  the  start  of 
the  first  action  in  the  plan.  Extending  the  protocol 
with  cancelation  messages  should  be  straight  for¬ 
ward. 

Once  the  execution  of  the  first  action  in  the  plan 
begins,  a  message  has  to  be  sent  informing  it  that 
the  action  has  been  started.  This  followed  by  mes¬ 
sages  about  achieved  effects  and  completion  of  the 
first  action.  This  is  effectively  the  performance 
block  introduced  in  section  16.1.  In  fact,  there  will 
be  one  such  block  of  messages  corresponding  to  ev¬ 
ery  action  in  the  plan.  This  allows  the  commanding 
agent  to  follow  execution  of  the  plan  in  detail. 

One  obvious  question  here  is  how  this  differs  from 
a  sequence  of  single  execution  commands  issued  by 
the  commander.  The  main  difference  is  that  the 
executing  agent  sees  the  whole  plan  at  once.  Thus, 
if  a  resource  for  an  activity  later  in  the  plan  is  not 
available,  the  executing  agent  can  reject  the  plan 
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Figure  16:  Protocol  for  Execution  Failure 

before  the  execution  of  the  first  action.  On  the 
other  hand,  if  the  commander  wants  to  change  the 
plan  during  execution,  and  extension  of  the  pro¬ 
tocol  would  be  required  allows  for  appropriate  in¬ 
tervention.  In  the  simplest  case  this  might  be  like 
abandoning  execution  of  the  current  action,  and 
therefore  quite  similar  to  the  protocol  described  in 
the  previous  section. 

17  Dealing  with  Execution 
Failure 

The  next  obvious  question  then  is  how  to  deal  with 
execution  failure.  By  execution  failure  we  mean 
any  situation  in  which  the  executing  agent  fails  to 
achieve  the  effects  that  are  in  the  shared  model  of 
action. 

17.1  Execution  Failure  Protocol 

A  partial  protocol  for  dealing  such  failures  is  shown 
in  figure  16.  The  part  up  the  execution  of  the  action 
is  not  included  as  this  cannot  lead  to  an  execution 
failure. 

The  protocol  is  shown  from  the  message  sent  to 
the  commander  that  indicates  that  execution  has 
begun.  This  may  lead  to  normal  execution  and 
messages  being  exchanged  as  described  in  the  “per¬ 
forming”  block  defined  above.  Let  us  assume  that, 
at  some  point  after  the  start  of  the  action,  execu¬ 
tion  fails.  This  means  an  expected  effect  did  not 
occur.  This  can  mean  that  either  nothing  has  been 


achieved  or,  that  an  alternative  outcome  occurred. 
In  either  case,  the  executing  agent  sends  a  mes¬ 
sage  to  the  commander  informing  it  that  it  failed 
to  achieve  an  expected  effect. 

The  commander  can  then  decide  whether  it 
wants  the  executing  agent  to  continue  with  the  ex¬ 
ecution  or  abandon  the  action.  This  assumes  that 
the  commander  is  aware  of  the  goal  structure  and 
can  decide  whether  the  effect  in  question  was  re¬ 
quired  for  a  subsequent  action.  If  it  was  not,  the 
failed  effect  will  not  influence  the  plan.  If  the  effect 
was  required  by  another  action  the  commander  will 
need  to  do  more  than  just  tell  the  executing  agent 
to  abandon  execution. 

17.2  Execution  Failure  and  Planning 

Execution  failure  is  not  a  new  problem  in  AI  plan¬ 
ning,  with  plan  repair  and  re-planning  being  the 
usual  approaches.  However,  these  approaches  are 
of  limited  applicability  as  they  are  only  dealing  with 
expectable  failure. 

The  underlying  problem  is  really  one  of  abstrac¬ 
tion.  When  setting  up  a  classic  planning  problem 
in  the  first  place,  it  is  important  to  abstract  away 
from  unnecessary  detail  in  order  to  keep  the  search 
space  as  small  as  possible.  Classic  AI  research  il¬ 
lustrates  how  this  can  be  done  [Amarel,  1968].  As 
a  result,  each  state  in  the  search  space  corresponds 
to  many  states  in  the  world  state. 

This  may  be  a  problem  when  execution  fails:  the 
world  state  in  which  an  agent  finds  itself  may  cor¬ 
respond  to  a  search  state  that  represents  success¬ 
ful  execution  of  an  action,  or  it  may  not  have  a 
corresponding  abstract  state  in  the  search  space. 
For  example,  in  a  route  planning  problem  we  may 
only  consider  specific  locations  in  states,  e.g.  cities. 
Then,  no  matter  where  in  a  city  the  agent  is,  the 
search  state  representing  this  world  state  is  the 
same.  And  if  an  agent  fails  to  get  from  one  city  to 
another,  its  actual  position  will  be  somewhere  along 
the  way,  which  does  not  correspond  to  a  search 
state  at  all.  Thus,  a  planner  would  never  find  a 
plan  that  recovers  this  agent,  unless  the  underly¬ 
ing  planning  problem  that  defines  the  search  state 
space  is  changed. 

So,  on  the  one  hand  we  need  to  abstract  away 
from  detail  to  create  a  small  search  space,  but  then 
when  plan  execution  fails,  we  may  need  to  be  able 
to  include  more  detail  to  deal  with  the  failure  at 
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hand.  Solving  this  problem  is  beyond  this  report. 

18  Results  and  Discussion 

This  report  describes  work  completed  towards  a 
new  framework  for  distributed  multi-agent  plan¬ 
ning  and  plan  execution.  The  first  step  has  fo¬ 
cussed  on  the  plan  representation  that  needs  to  be 
sufficiently  rich  to  allow  the  sharing  of  plans  be¬ 
tween  humans,  software  systems,  and  robotic  enti¬ 
ties.  The  basis  for  this  representation  is  the  Core 
Plan  Representation  discussed  in  section  3  and  the 
BDI  model  of  agency  discussed  in  section  4. 

The  main  result  of  this  work  then  is  a  combined 
and  refined  ontological  model  for  rich  plan  rep¬ 
resentations.  This  model  includes  concepts  that 
will  be  required  for  a  sharable  plan  representation 
intended  for  distributed  multi-agent  planning  and 
plan  execution. 

While  the  first  part  of  this  report  does  specify 
the  ontology  that  constitutes  the  merged  represen¬ 
tation,  it  does  not  specify  a  specific  syntax  for  the 
representation.  Furthermore,  a  meta-level  will  be 
required  for  communicating  plans,  allowing  agents 
to  not  only  share  plans,  but  also  to  tell  other  agent 
what  they  expect  them  to  do  with  the  communi¬ 
cated  plan.  This  will  require  a  set  of  performatives 
for  working  with  shared  plans. 

This  next  part  of  this  report  addresses  this 
shortfall.  It  describes  an  implementation  of  the 
CPR/BDI  framework  that  comes  in  the  form  of  an 
extension  to  the  MediaWiki  software.  This  exten¬ 
sion  defines  a  number  of  XML  tags  that  can  be  used 
to  mark  up  procedural  knowledge  in  a  wiki  arti¬ 
cle,  resulting  in  a  semi-formal  representation  over¬ 
all.  The  advantage  of  using  MediaWiki  is  that  it 
implements  Web  2.0  style  information  sharing  in  a 
robust  framework.  The  extension  we  provide  makes 
it  possible  to  represent  procedural  knowledge  with 
enough  formalism  to  make  it  accessible  to  reasoning 
engines  such  as  AI  planners. 

This  report  has  also  defined  four  planning  do¬ 
main  features  that  can  be  used  by  knowledge  en¬ 
gineers  to  provide  information  about  the  domain 
they  are  encoding.  The  formal  definition  of  the 
features  was  used  to  design  algorithms  that  can  ex¬ 
tract  the  actual  feature  values  from  the  domain  de¬ 
scription.  The  algorithms  are  based  on  the  domain 
description  only,  i.e.  they  do  not  require  a  plan¬ 


ning  problem  as  input.  The  extracted  features  can 
then  be  compared  to  the  feature  values  specified 
by  the  domain  author  to  validate  the  domain  de¬ 
scription.  This  approach  has  been  evaluated  using 
domains  taken  mostly  from  the  international  plan¬ 
ning  competition.  The  result  shows  that  features 
were  consistent  with  those  available  in  the  domains, 
where  explicitly  specified.  Those  features  that  were 
not  specified  were  extracted  and  manually  verified, 
to  ensure  they  are  consistent  with  the  given  set  of 
operators. 

The  first  feature,  the  type  system,  is  a  rather 
simple,  flat  division  into  equivalence  classes.  This 
may  not  be  suitable  for  very  complex  planning  do¬ 
mains,  but  the  domains  we  have  analyzed  do  not 
exhibit  much  hierarchical  structure.  The  advantage 
of  such  a  type  system  is  that  it  can  be  easily  added 
to  the  operator  descriptions  in  the  form  of  unary 
preconditions.  Furthermore,  we  showed  that  the 
type  system  derived  by  our  algorithm  is  the  most 
specific  type  system  of  its  kind  based  solely  on  the 
operator  descriptions.  An  open  question  is  whether 
this  is  identical  to  the  least  general  generalization 
[Plotkin,  1969]  used  in  machine  learning.  The  algo¬ 
rithm  could  be  refined  to  derive  a  hierarchical  type 
system  if  one  takes  into  account  the  directionality 
of  the  operators,  but  for  a  type  system  consisting  of 
equivalence  classes  this  is  irrelevant.  Also,  the  al¬ 
gorithm  described  in  this  paper  should  also  be  ap¬ 
plicable  to  hierarchical  task  network  domains,  but 
this  has  not  yet  been  implemented. 

Actions  with  inconsistent  effects  are  another  fea¬ 
ture  we  have  defined.  For  most  domains,  such  ac¬ 
tions  are  probably  not  desirable.  In  fact,  the  ad¬ 
mission  of  such  actions  leads  to  a  different  planning 
problem  as  the  state  spaces  with  or  without  such 
actions  may  be  different  for  the  same  planning  do¬ 
main  and  problem.  Also,  planners  that  translate  a 
strips  planning  problem  (with  negative  precondi¬ 
tions)  into  a  propositional  problem  (without  neg¬ 
ative  preconditions)  need  to  be  more  careful  if  ac¬ 
tions  with  inconsistent  effects  are  permitted.  The 
translation  method  described  in  [Ghallab  et  al. , 
2004,  section  2.6]  does  not  work  in  this  case  as  it 
introduces  independent  predicates  for  a  predicate 
and  its  negations,  which  can  become  true  in  the 
same  state  if  an  action  with  inconsistent  effects  is 
applied.  This  would  render  the  planner  potentially 
unsound. 

The  final  feature  which  defines  reversible  actions 
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is  somewhat  different  as  it  can  only  be  usefully  used 
as  a  necessary  criterion  to  test  whether  one  oper¬ 
ator  is  the  reverse  of  another.  The  more  strict, 
sufficient  definition  does  not  provide  any  compu¬ 
tational  advantage.  The  difference  is  simply  that 
the  necessary  criterion  can  be  computed  on  the  ba¬ 
sis  of  the  operator  descriptions,  whereas  the  suffi¬ 
cient  test  requires  knowledge  of  the  state  in  which 
an  action  is  applied.  The  difference  is  quite  sub¬ 
tle  though,  and  may  not  matter  in  practice.  The 
necessary  criterion  requires  the  positive  and  nega¬ 
tive  effects  to  cancel  each  other.  However,  if  a  state 
contains  an  atom  that  is  also  added  by  the  first  ac¬ 
tion,  but  then  deleted  by  the  second  action,  then 
the  state  will  be  changed.  If  an  operator  listed  all 
the  relevant  atoms  also  as  preconditions,  this  ex¬ 
ception  would  not  hold. 

Finally,  we  have  looked  at  established  agent  com¬ 
munication  frameworks  with  the  focus  on  support 
they  might  provide  for  distributed  plan  execution. 
The  message  structure  in  the  analyzed  frameworks 
is  rather  similar  and  seems  sufficiently  expressive. 
Much  rests  on  the  performatives  in  the  two  frame¬ 
works  as  these  define  the  communicative  acts  to 
the  agents.  However,  communicative  acts  do  oc¬ 
cur  in  isolation,  and  it  is  the  interaction  protocols 
that  defines  the  context  in  which  performatives  are 
to  be  used.  The  FIPA  agent  framework  is  more 
advanced  in  this  respect  and  comes  closer  to  our 
needs  by  defining  a  protocol  specifically  for  the  dis¬ 
tributed  execution  of  an  action.  This  protocol  has 
formed  the  basis  for  our  own  protocols  described  in 
this  report. 

Having  defined  a  number  of  protocols  it  is  now 
possible  to  go  back  and  analyze  them  in  terms  of 
communicative  acts  required.  The  following  is  a 
list  of  all  the  message  types  used  in  the  protocols 
for  distributed  plan  execution: 

•  command:  the  commanding  agent  issues  a  com¬ 
mand;  the  content  is  a  description  of  the  com¬ 
manded  activity;  corresponds  to  the  request 
performative  in  FIPA; 

•  reject:  the  executing  agent  rejects  the  com¬ 
mand;  no  content  required;  corresponds  to  the 
refuse  performative  in  FIPA; 

•  accept:  the  executing  agent  accepts  the  com¬ 
mand;  no  content  required;  corresponds  to  the 
agree  performative  in  FIPA; 


•  renege:  the  executing  agent  reneges  the  com¬ 
mand;  the  content  is  a  reference  to  the  action 
in  question;  no  corresponding  performative  in 
FIPA; 

•  started:  the  executing  agent  starts  the  exe¬ 
cution;  the  content  is  a  reference  to  the  action 
in  question;  could  use  inform  performative  in 
FIPA  to  convey  this  message; 

•  achieved:  the  executing  agent  has  achieved 
and  effect;  the  content  is  a  reference  to  the 
effect  of  an  action;  could  use  inform  perfor¬ 
mative  in  FIPA  to  convey  this  message; 

•  completed:  the  executing  agent  has  completed 
the  execution;  the  content  is  a  reference  to  the 
action  in  question;  could  use  inform  performa¬ 
tive  in  FIPA  to  convey  this  message; 

•  abandon:  the  commander  instructs  the  execu¬ 
tion  agent  to  terminate  execution  (now);  the 
content  is  a  reference  to  the  action  in  ques¬ 
tion;  corresponds  to  the  cancel  performative 
in  FIPA; 

•  failed:  the  executing  agent  has  failed  to 
achieve  an  effect;  the  content  is  a  reference  to 
the  effect  of  an  action;coulcl  use  inform  per¬ 
formative  in  FIPA  to  convey  this  message; 

•  continue:the  commander  instructs  the  exe¬ 
cuting  agent  to  continue  with  the  execution; 
the  content  is  a  reference  to  the  action  in  ques¬ 
tion;  no  corresponding  performative  in  FIPA; 

As  can  be  seen,  the  majority  of  the  performa¬ 
tives  required  is  already  used  for  the  simplest  pro¬ 
tocol.  This  indicates  that  the  set  of  performatives 
required  for  even  more  complex  protocols  could  be 
quite  limited,  rendering  an  implementation  feasi¬ 
ble. 

19  Conclusions 

Generative  planning  is  a  computationally  difficult 
problem.  Putting  plans  in  a  wider  context  is  a  con¬ 
ceptually  difficult  problem  in  the  sense  that  there  is 
no  single,  agreed-upon  definition  of  the  plan  com¬ 
munication  or  execution  problem.  The  report  de¬ 
scribes  work  towards  a  framework  that  addresses 
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these  problems,  even  if  there  is  no  formal  defini¬ 
tion. 

The  first  step  has  been  an  ontological  analysis 
of  a  plan.  If  plans  are  to  be  communicated,  it 
needs  to  be  agreed  what  constitutes  a  plan,  and  an 
ontological  view  defining  relevant  concepts  is  the 
normal  way  of  going  about  this.  We  have  imple¬ 
mented  this  view  in  the  context  of  a  wiki,  allowing 
for  shared  and  distributed  knowledge  engineering 
of  planning  knowledge.  One  of  the  most  interesting 
lessons  learned  from  this  work  is  perhaps  the  fact 
that  there  is  much  in  the  formal  definition  of  a  plan¬ 
ning  domain,  that  is  not  explicit.  This  is  a  serious 
problem  when  it  comes  to  knowledge  sharing,  or 
maintaining  the  formal  representation.  To  address 
this  problem  we  have  developed  a  number  of  algo¬ 
rithms  that  analyze  a  domain  in  terms  of  features 
that  could  also  be  specified  in  the  formal  definition. 
If  these  formal  definition  and  the  extracted  features 
are  different,  this  indicates  a  problem  with  the  do¬ 
main  definition.  Also,  the  explicit  representation 
will  help  others  to  better  understand  the  domain. 

The  ontology  developed  in  the  first  part  is  for 
describing  plans.  The  meta-level  developed  in  the 
final  part  of  the  project  defines  a  number  of  perfor¬ 
matives  and  protocols  that  can  be  used  during  the 
execution  of  a  plan.  This  should  make  it  possible 
to  control  the  execution  at  least  to  a  limited  degree 
in  a  formal  way. 
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AI  -  Artificial  Intelligence 

BDI  -  Beliefs,  Desires  and  Intentions 

CPR  -  Core  Plan  Representation 

HTN  -  Hierarchical  Task  Network 

PDDL  -  Planning  Domain  Definition  Language 
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